服務(wù)器時鐘回?fù)軙?dǎo)致產(chǎn)生重復(fù)的 ID，SNOWFLAKE 方案中對原有雪花算法做了改進(jìn)，增加了一個最大容忍的時鐘回?fù)芎撩霐?shù)。

如果時鐘回?fù)艿臅r間超過最大容忍的毫秒數(shù)閾值，則程序直接報錯;如果在可容忍的范圍內(nèi)，默認(rèn)分布式主鍵生成器，會等待時鐘同步到最后一次主鍵生成的時間后再繼續(xù)工作。

最大容忍的時鐘回?fù)芎撩霐?shù)，默認(rèn)值為 0，可通過屬性 max.tolerate.time.difference.milliseconds 設(shè)置。

# 最大容忍的時鐘回?fù)芎撩霐?shù) 
spring.shardingsphere.sharding.tables.t_order.key-generator.max.tolerate.time.difference.milliseconds=5 

下面是看下它的源碼實(shí)現(xiàn)類 SnowflakeShardingKeyGenerator，核心流程大概如下：

最后一次生成主鍵的時間 lastMilliseconds 與 當(dāng)前時間currentMilliseconds 做比較，如果 lastMilliseconds > currentMilliseconds則意味著時鐘回調(diào)了。

那么接著判斷兩個時間的差值(timeDifferenceMilliseconds)是否在設(shè)置的最大容忍時間閾值 max.tolerate.time.difference.milliseconds內(nèi)，在閾值內(nèi)則線程休眠差值時間 Thread.sleep(timeDifferenceMilliseconds)，否則大于差值直接報異常。

/** 
 * @author xiaofu 
 */ 
public final class SnowflakeShardingKeyGenerator implements ShardingKeyGenerator{ 
    @Getter 
    @Setter 
    private Properties properties = new Properties(); 
     
    public String getType() { 
        return "SNOWFLAKE"; 
    } 
     
    public synchronized Comparable<?> generateKey() { 
     /** 
      * 當(dāng)前系統(tǒng)時間毫秒數(shù)  
      */  
        long currentMilliseconds = timeService.getCurrentMillis(); 
        /** 
         * 判斷是否需要等待容忍時間差，如果需要，則等待時間差過去，然后再獲取當(dāng)前系統(tǒng)時間  
         */  
        if (waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) { 
            currentMilliseconds = timeService.getCurrentMillis(); 
        } 
        /** 
         * 如果最后一次毫秒與 當(dāng)前系統(tǒng)時間毫秒相同，即還在同一毫秒內(nèi)  
         */ 
        if (lastMilliseconds == currentMilliseconds) { 
         /** 
          * &位與運(yùn)算符：兩個數(shù)都轉(zhuǎn)為二進(jìn)制，如果相對應(yīng)位都是1，則結(jié)果為1，否則為0 
          * 當(dāng)序列為4095時，4095+1后的新序列與掩碼進(jìn)行位與運(yùn)算結(jié)果是0 
          * 當(dāng)序列為其他值時，位與運(yùn)算結(jié)果都不會是0 
          * 即本毫秒的序列已經(jīng)用到最大值4096，此時要取下一個毫秒時間值 
          */ 
            if (0L == (sequence = (sequence + 1) & SEQUENCE_MASK)) { 
                currentMilliseconds = waitUntilNextTime(currentMilliseconds); 
            } 
        } else { 
         /** 
          * 上一毫秒已經(jīng)過去，把序列值重置為1  
          */ 
            vibrateSequenceOffset(); 
            sequence = sequenceOffset; 
        } 
        lastMilliseconds = currentMilliseconds; 
         
        /** 
         * XX......XX XX000000 00000000 00000000 時間差 XX 
         *    XXXXXX XXXX0000 00000000 機(jī)器ID XX 
         *               XXXX XXXXXXXX 序列號 XX 
         *  三部分進(jìn)行|位或運(yùn)算：如果相對應(yīng)位都是0，則結(jié)果為0，否則為1 
         */ 
        return ((currentMilliseconds - EPOCH) << TIMESTAMP_LEFT_SHIFT_BITS) | (getWorkerId() << WORKER_ID_LEFT_SHIFT_BITS) | sequence; 
    } 
     
    /** 
     * 判斷是否需要等待容忍時間差 
     */ 
    @SneakyThrows 
    private boolean waitTolerateTimeDifferenceIfNeed(final long currentMilliseconds) { 
     /** 
      * 如果獲取ID時的最后一次時間毫秒數(shù)小于等于當(dāng)前系統(tǒng)時間毫秒數(shù)，屬于正常情況，則不需要等待  
      */ 
        if (lastMilliseconds <= currentMilliseconds) { 
            return false; 
        } 
        /** 
         * ===>時鐘回?fù)艿那闆r（生成序列的時間大于當(dāng)前系統(tǒng)的時間），需要等待時間差  
         */ 
        /** 
         * 獲取ID時的最后一次毫秒數(shù)減去當(dāng)前系統(tǒng)時間毫秒數(shù)的時間差  
         */ 
        long timeDifferenceMilliseconds = lastMilliseconds - currentMilliseconds; 
        /** 
         * 時間差小于最大容忍時間差，即當(dāng)前還在時鐘回?fù)艿臅r間差之內(nèi)  
         */ 
        Preconditions.checkState(timeDifferenceMilliseconds < getMaxTolerateTimeDifferenceMilliseconds(),  
                "Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds", lastMilliseconds, currentMilliseconds); 
        /** 
         * 線程休眠時間差  
         */ 
        Thread.sleep(timeDifferenceMilliseconds); 
        return true; 
    } 
     
    // 配置的機(jī)器ID 
    private long getWorkerId() { 
        long result = Long.valueOf(properties.getProperty("worker.id", String.valueOf(WORKER_ID))); 
        Preconditions.checkArgument(result >= 0L && result < WORKER_ID_MAX_VALUE); 
        return result; 
    } 
     
    private int getMaxTolerateTimeDifferenceMilliseconds() { 
        return Integer.valueOf(properties.getProperty("max.tolerate.time.difference.milliseconds", String.valueOf(MAX_TOLERATE_TIME_DIFFERENCE_MILLISECONDS))); 
    } 
     
    private long waitUntilNextTime(final long lastTime) { 
        long result = timeService.getCurrentMillis(); 
        while (result <= lastTime) { 
            result = timeService.getCurrentMillis(); 
        } 
        return result; 
    } 
} 

但從 SNOWFLAKE 方案生成的主鍵ID 來看，order_id 它是一個18位的長整型數(shù)字，是不是發(fā)現(xiàn)它太長了，想要 MySQL 那種從 0 遞增的自增主鍵該怎么實(shí)現(xiàn)呢?別急，后邊已經(jīng)會給出了解決辦法!

自定義

sharding-jdbc 利用 SPI 全稱( Service Provider Interface) 機(jī)制拓展主鍵生成規(guī)則，這是一種服務(wù)發(fā)現(xiàn)機(jī)制，通過掃描項目路徑 META-INF/services 下的文件，并自動加載文件里所定義的類。

實(shí)現(xiàn)自定義主鍵生成器其實(shí)比較簡單，只有兩步。

第一步，實(shí)現(xiàn) ShardingKeyGenerator 接口，并重寫其內(nèi)部方法，其中 getType() 方法為自定義的主鍵生產(chǎn)方案類型、generateKey() 方法則是具體生成主鍵的規(guī)則。

下面代碼中用 AtomicInteger 來模擬實(shí)現(xiàn)一個有序自增的 ID 生成。

/** 
 * @Author: xiaofu 
 * @Description: 自定義主鍵生成器 
 */ 
@Component 
public class MyShardingKeyGenerator implements ShardingKeyGenerator { 
 
 
    private final AtomicInteger count = new AtomicInteger(); 
 
    /** 
     * 自定義的生成方案類型 
     */ 
    @Override 
    public String getType() { 
        return "XXX"; 
    } 
 
    /** 
     * 核心方法-生成主鍵ID 
     */ 
    @Override 
    public Comparable<?> generateKey() { 
        return count.incrementAndGet(); 
    } 
 
    @Override 
    public Properties getProperties() { 
        return null; 
    } 
 
    @Override 
    public void setProperties(Properties properties) { 
 
    } 
} 

第二步，由于是利用 SPI 機(jī)制實(shí)現(xiàn)功能拓展，我們要在 META-INF/services 文件中配置自定義的主鍵生成器類路勁。

com.xiaofu.sharding.key.MyShardingKeyGenerator 

上面這些弄完我們測試一下，配置定義好的主鍵生成類型 XXX，并插入幾條數(shù)據(jù)看看效果。

spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id 
spring.shardingsphere.sharding.tables.t_order.key-generator.type=XXX 

通過控制臺的SQL 解析日志發(fā)現(xiàn)，order_id 字段已按照有序自增的方式插入記錄，說明配置的沒問題。

舉一反九

既然可以自定義生成方案，那么實(shí)現(xiàn)分布式主鍵的思路就很多了，又想到之前我寫的這篇 《9種 分布式ID生成方案》，發(fā)現(xiàn)可以完美兼容，這里挑選其中的 滴滴(Tinyid)來實(shí)踐一下，由于它是個單獨(dú)的分布式ID生成服務(wù)，所以要先搭建環(huán)境了。

Tinyid 的服務(wù)提供Http 和 Tinyid-client 兩種接入方式，下邊使用 Tinyid-client 方式快速使用，更多的細(xì)節(jié)到這篇文章里看吧，實(shí)在是介紹過太多次了。

Tinyid 服務(wù)搭建

先拉源代碼 https://github.com/didi/tinyid.git。

由于是基于號段模式實(shí)現(xiàn)的分布式ID，所以依賴于數(shù)據(jù)庫，要創(chuàng)建相應(yīng)的表 tiny_id_info 、tiny_id_token 并插入默認(rèn)數(shù)據(jù)。

CREATE TABLE `tiny_id_info` ( 
 `id` BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵', 
 `biz_type` VARCHAR (63) NOT NULL DEFAULT '' COMMENT '業(yè)務(wù)類型，唯一', 
 `begin_id` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '開始id，僅記錄初始值，無其他含義。初始化時begin_id和max_id應(yīng)相同', 
 `max_id` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '當(dāng)前最大id', 
 `step` INT (11) DEFAULT '0' COMMENT '步長', 
 `delta` INT (11) NOT NULL DEFAULT '1' COMMENT '每次id增量', 
 `remainder` INT (11) NOT NULL DEFAULT '0' COMMENT '余數(shù)', 
 `create_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創(chuàng)建時間', 
 `update_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間', 
 `version` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '版本號', 
 PRIMARY KEY (`id`), 
 UNIQUE KEY `uniq_biz_type` (`biz_type`) 
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'id信息表'; 
 
CREATE TABLE `tiny_id_token` ( 
 `id` INT (11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增id', 
 `token` VARCHAR (255) NOT NULL DEFAULT '' COMMENT 'token', 
 `biz_type` VARCHAR (63) NOT NULL DEFAULT '' COMMENT '此token可訪問的業(yè)務(wù)類型標(biāo)識', 
 `remark` VARCHAR (255) NOT NULL DEFAULT '' COMMENT '備注', 
 `create_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創(chuàng)建時間', 
 `update_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間', 
 PRIMARY KEY (`id`) 
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'token信息表'; 
 
INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) VALUES ('1', '0f673adf80504e2eaa552f5d791b644c', 'order', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48'); 
 
INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`) VALUES ('1', 'order', '1', '1', '100000', '1', '0', '2018-07-21 23:52:58', '2018-07-22 23:19:27', '1'); 

并在 Tinyid 服務(wù)中配置上邊表所在數(shù)據(jù)源信息

datasource.tinyid.primary.url=jdbc:mysql://47.93.6.e:3306/ds-0?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8 
datasource.tinyid.primary.username=root 
datasource.tinyid.primary.password=root 

最后項目 maven install ，右鍵 TinyIdServerApplication 啟動服務(wù)， Tinyid 分布式ID生成服務(wù)就搭建完畢了。

自定義 Tinyid 主鍵類型

Tinyid 服務(wù)搭建完下邊在項目中引入它，新建個 tinyid_client.properties 文件其中添加 tinyid.server 和 tinyid.token 屬性，token 為之前 SQL 預(yù)先插入的用戶數(shù)據(jù)。

# tinyid 分布式ID 
# 服務(wù)地址 
tinyid.server=127.0.0.1:9999 
# 業(yè)務(wù)token 
tinyid.token=0f673adf80504e2eaa552f5d791b644c 

代碼中獲取 ID更簡單，只需一行代碼，業(yè)務(wù)類型 order 是之前 SQ L 預(yù)先插入的數(shù)據(jù)。

Long id = TinyId.nextId("order"); 

我們開始自定義 Tinyid 主鍵生成類型的實(shí)現(xiàn)類 TinyIdShardingKeyGenerator 。

/** 
 * @Author: xiaofu 
 * @Description: 自定義主鍵生成器 
 */ 
@Component 
public class TinyIdShardingKeyGenerator implements ShardingKeyGenerator { 
     
    /** 
     * 自定義的生成方案類型 
     */ 
    @Override 
    public String getType() { 
        return "tinyid"; 
    } 
 
    /** 
     * 核心方法-生成主鍵ID 
     */ 
    @Override 
    public Comparable<?> generateKey() { 
         
        Long id = TinyId.nextId("order"); 
         
        return id; 
    } 
 
    @Override 
    public Properties getProperties() { 
        return null; 
    } 
 
    @Override 
    public void setProperties(Properties properties) { 
 
    } 
} 

并在配置文件中啟用 Tinyid 主鍵生成類型，到此配置完畢，趕緊測試一下。

# 主鍵字段 
spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id 
# 主鍵ID 生成方案 
spring.shardingsphere.sharding.tables.t_order.key-generator.type=tinyid 

測試 Tinyid 主鍵

向數(shù)據(jù)庫插入訂單記錄測試發(fā)現(xiàn)，主鍵ID字段 order_id 已經(jīng)為趨勢遞增的了， Tinyid 服務(wù)成功接入，完美!

總結(jié)

后續(xù)的八種生成方式大家參考 《9種 分布式ID生成方案》 按需接入吧，整體比較簡單這里就不依次實(shí)現(xiàn)了。

案例 GitHub 地址：https://github.com/chengxy-nds/Springboot-Notebook/tree/master/springboot-sharding-jdbc劉一手

原文鏈接：https://mp.weixin.qq.com/s/x1gVtnKh2OEAzSwv0sFDxg