4. sharding-jdbc源码之分布式ID

阿飞Javaer，转载请注明原创出处，谢谢！

实现动机

传统数据库软件开发中，主键自动生成技术是基本需求。而各大数据库对于该需求也提供了相应的支持，比如MySQL的自增键。 对于MySQL而言，分库分表之后，不同表生成全局唯一的Id是非常棘手的问题。因为同一个逻辑表内的不同实际表之间的自增键是无法互相感知的， 这样会造成重复Id的生成。我们当然可以通过约束表生成键的规则来达到数据的不重复，但是这需要引入额外的运维力量来解决重复性问题，并使框架缺乏扩展性。

目前有许多第三方解决方案可以完美解决这个问题，比如UUID等依靠特定算法自生成不重复键（由于InnoDB采用的B+Tree索引特性，UUID生成的主键插入性能较差），或者通过引入Id生成服务等。 但也正因为这种多样性导致了Sharding-JDBC如果强依赖于任何一种方案就会限制其自身的发展。

基于以上的原因，最终采用了以JDBC接口来实现对于生成Id的访问，而将底层具体的Id生成实现分离出来。

摘自sharding-jdbc分布式主键

sharding-jdbc的分布式ID采用twitter开源的snowflake算法，不需要依赖任何第三方组件，这样其扩展性和维护性得到最大的简化；但是snowflake算法的缺陷（强依赖时间，如果时钟回拨，就会生成重复的ID），sharding-jdbc没有给出解决方案，如果用户想要强化，需要自行扩展；

扩展：美团的分布式ID生成系统也是基于snowflake算法，并且解决了时钟回拨的问题，读取有兴趣请阅读Leaf——美团点评分布式ID生成系统

分布式ID简介

github上对分布式ID这个特性的描述是：Distributed Unique Time-Sequence Generation，两个重要特性是：分布式唯一和时间序；基于Twitter Snowflake算法实现，长度为64bit；64bit组成如下：
* 1bit sign bit.
* 41bits timestamp offset from 2016.11.01(Sharding-JDBC distributed primary key published data) to now.
* 10bits worker process id.
* 12bits auto increment offset in one mills.

分布式ID源码分析

核心源码在sharding-jdbc-core模块中的com.dangdang.ddframe.rdb.sharding.keygen.DefaultKeyGenerator.java中：

public final class DefaultKeyGenerator implements KeyGenerator {
   

    public static final long EPOCH;

    // 自增长序列的长度（单位是位时的长度）
    private static final long SEQUENCE_BITS = 12L;

    // workerId的长度（单位是位时的长度）
    private static final long WORKER_ID_BITS = 10L;

    private static final long SEQUENCE_M