当使用分库分表等功能之后,就不能再依赖数据库自带的主键生成机制了,一方面主键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