标签:JDBC Sequence 数据库 生成 Sharding 服务器 ID 主键
当使用分库分表等功能之后,就不能再依赖数据库自带的主键生成机制了,一方面主键ID不能重复,另外需要在新增之前就知道主键ID,才能保证ID能够均匀分布到不同的数据库或数据表中,所以要使用一个合理的主键生成策略。
1. UUID
使用UUID作主键是最简单的方案,但是缺点也是非常明显的。由于UUID非常的长,并需要使用字符串存储,除占用大量存储空间外,最主要的问题是在索引上,在建立索引和基于索引进行查询时都存在性能问题。
2. 主键生成器
Sharding-jdbc提供主键生成器,就是一个会生成不重复Long值的类。该生成器生成的数据为64bit的long型数据,数据库中应该用大于等于64bit的数字类型的字段来保存该值,比如在MySQL中应该使用BIGINT。
添加依赖:
<dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-self-id-generator</artifactId> <version>1.4.2</version> </dependency>
在@Configuration类中创建Bean对象
@Bean public IdGenerator getIdGenerator() { return new CommonSelfIdGenerator(); }
使用Bean对象
@Autowired private IdGenerator idGenerator; @Test public void generateId(){ long id = idGenerator.generateId().longValue(); }
3. 使用数据表做ID生成服务器
建立两台以上的数据库ID生成服务器,每个服务器都有一张记录各表当前ID的Sequence表,但是Sequence中ID增长的步长是服务器的数量,起始值依次错开,这样相当于把ID的生成散列到了每个服务器节点上。例如:如果我们设置两台数据库ID生成服务器,那么就让一台的Sequence表的ID起始值为1,每次增长步长为2,另一台的Sequence表的ID起始值为2,每次增长步长也为2,那么结果就是奇数的ID都将从第一台服务器上生成,偶数的ID都从第二台服务器上生成,这样就将生成ID的压力均匀分散到两台服务器上,同时配合应用程序的控制,当一个服务器失效后,系统能自动切换到另一个服务器上获取ID,从而保证了系统的容错。
参考资料:https://blog.csdn.net/dfhjryvx/article/details/83896306
标签:JDBC,Sequence,数据库,生成,Sharding,服务器,ID,主键 来源: https://www.cnblogs.com/huanshilang/p/12088261.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。