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