Sharding-JDBC主键生成策略

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

上一篇:sharding-jdbc水平分库分表,广播表


下一篇:面试官问我:看过sharding-jdbc的源码吗?我吧啦吧啦说了一通!!