从给apache sharding-sphere提交的issue再谈分布式ID

很多的分布式系统的唯一ID都是基于雪花算法生成的，apache sharding-sphere的分布式ID也是采用了雪花算法：

snowflake

由上图可知，雪花算法的几个核心组成部分：

1. 1位标识位​；
2. 41位时间戳；
3. 10位workId（数据中心+工作机器，可以其他组成方式）；
4. 12位自增序列；

分析一下雪花算法这三部分：

• 自增序列，是不会出问题的，generateKey()时由synchronized保证。如果你不加这个关键词或者用其他方式控制并发，从而导致产生重复的ID，那不是雪花算法的问题（说明：不考虑每毫秒超过1024次ID生成）；
• 机器ID，只要按照约定规划好，也不会出现重复问题。至于机器ID重复导致产生重复的ID，那也是使用者的问题，雪花算法也不背这个锅；
• 时间戳，就是这部分。雪花算法最难解决的部分，即时钟回拨导致产生重复的ID。

笔者对sharding-sphere提的关于优化分布式ID的ISSUE地址：https://github.com/apache/incubator-shardingsphere/issues/1596，截图如下：

issue-1596

算法优化1

低并发下，导致产生的大部分分布式ID的自增序列值都是0（只需要满足并发低于1000TPS，事实上很多的系统的TPS是低于这个值的），从而可能导致以分布式ID为分片键的业务数据会发生倾斜。

生成ID的核心代码如下：

return ((currentMillis - EPOCH) << 22) | (workerId << 12) | sequence;

如果并发过低，每次生成分布式ID时都是一个新的毫秒值，那么，每次的sequence的值就都是0。如此一来，每次生成的分布式ID都是偶数。基于sharding-jdbc-2.0.3，验证代码如下：

public class IdTest {
    public static void main(String[] args) throws Exception {
        DefaultKeyGenerator keyGenerator = new DefaultKeyGenerator();
        DefaultKeyGenerator.setWorkerId(1L);
        for (int i = 0; i < 10; i++) {
            System.out.println(keyGenerator.generateKey().longValue());
            // 模仿并发过低
            Thread.sleep(1);
        }
    }
}

这段代码就会导致生成的10个ID都是偶数，如果以这些ID作为分片键，并且分片算法采用直接取模的方式，就会导致数据全部分布在偶数表中，而奇数表中没有任何数据。解决办法：

1. 如笔者ISSUE中提到的，每次一个新的毫秒值时，sequence不是从0开始，而是从一个随机值开始。
2. 如亮哥最后修改的代码，每次的sequence在0和1之间不断变换（参考vibrateSequenceOffset方法）。

美团开源的leaf采用的第一种方案，详情请戳链接：https://github.com/Meituan-Dianping/Leaf/blob/master/leaf-core/src/main/java/com/sankuai/inf/leaf/snowflake/SnowflakeIDGenImpl.java，核心源码：sequence = RANDOM.nextInt(100);。

算法优化2

初看雪花算法中时间戳这部分稳的很，时间都是绝对递增的嘛。但是服务器上的时间偏偏就不一定是绝对递增的，你说气人不。所以，sharding-sphere-3.1.0的分布式ID相比2.0.3版本，针对时钟回拨问题有进行一些优化：

• 容忍时间等待

即当时间只是回拨了能容忍的时间（例如5ms），那么只需sleep即可，核心源码如下：

    @SneakyThrows
    private boolean waitTolerateTimeDifferenceIfNeed(final long currentMilliseconds) {
        if (lastMilliseconds <= currentMilliseconds) {
            return false;
        }
        long timeDifferenceMilliseconds = lastMilliseconds - currentMilliseconds;
        Preconditions.checkState(timeDifferenceMilliseconds < maxTolerateTimeDifferenceMilliseconds, 
                "Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds", lastMilliseconds, currentMilliseconds);
        Thread.sleep(timeDifferenceMilliseconds);
        return true;
    }

2. 其他优化

sharding-jdbc对于时钟回拨超过容忍时间，其实现是直接抛出异常（Preconditions.checkState... ...）。这种实现算法也是在不引入其他中间件的情况下，不得已的选择。

如果你能接受时钟回拨太多时（即超过最大容忍时间），抛出异常的处理逻辑，那么经过上面的优化，已经是一个非常不错的分布式ID实现方案了。如果还想继续优化，可以参考（笔者接下来也会撰文分析这两个开源方案）：

1. 百度的uid-generator：https://github.com/baidu/uid-generator；
2. 美团的leaf：https://github.com/Meituan-Dianping/Leaf；

另辟蹊径

下面几个数值是笔者淘宝上的几个订单ID（你也可以查看自己的淘宝订单进行验证）：

417536992624556188
415513089477556188
387944064796556188

有没有发现非常有规律？是的，就是时间属性+一段固定长度数值（6位长度，类用户ID）。这种生成唯一ID的方式，在特定的场景下非常高效。首先，不用担心重复问题（总不至于同一个用户在同一秒下订单吧，有也是非法订单）；其次，这种唯一ID的生成方式不需要依赖任何组件或者服务，性能和可用性都是最高。但是，缺点就是这种ID一定要是以用户（或者其他有区分度的属性）为维度的场景，这样才能保证它的唯一性。如果是物品表的分布式ID，很明显就不能用这种方式生成了（时间戳+卖家ID？好吧，我这个反例没举好，你说气人不）。