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. Redis

　　使用Redis的increment命令，可以生成递增Long类型数字。因为Redis是单线程的，可以保证是唯一ID。

 

4. 使用数据表做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