分布式唯一 id： snowflake 算法思考

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2507 天前的主题，其中的信息可能已经有所发展或是发生改变。

匠心零度转载请注明原创出处，谢谢！

缘起

为什么会突然谈到分布式唯一 id 呢？原因是最近在准备使用 RocketMQ，看看官网介绍：

一句话，消息可能会重复，所以消费端需要做幂等。为什么消息会重复后续 RocketMQ 章节进行详细介绍，本节重点不在这里。

为了达到业务的幂等，必须要有这样一个 id 存在，需要满足下面几个条件：

同一业务场景要全局唯一。
该 id 必须是在消息的发送方进行产生发送到 MQ。
消费端根据该 id 进行判断是否重复，确保幂等。

在那里产生，和消费端进行判断等和这个 id 没有关系，这个 id 的要求就是局部唯一或者全局唯一即可，由于这个 id 是唯一的，可以用来当数据库的主键，既然要做主键那么之前刚刚好发过一篇文章：从开发者角度谈 Mysql （ 1 ）：主键问题，文章重点提到为什么需要自增、或者趋势自增的好处。（和 Mysql 数据存储做法有关）。

那么该 id 需要有 2 个特性：

局部、全局唯一。
趋势递增。

如果有方法可以生成全局唯一（那么在局部也一定唯一了），生成分布式唯一 id 的方法有很多。大家可以看看分布式系统唯一 ID 生成方案汇总： http://www.cnblogs.com/haoxinyue/p/5208136.html （由于微信不是他的地址都显示不出来，所以把地址贴出来下），这个文章里面提到了很多以及各各的优缺点。本文关注重点是 snowflake 算法，该算法实现得到的 id 就满足上面提到的 2 点。

snowflake 算法

snowflake 是 Twitter 开源的分布式 ID 生成算法，结果是一个 long 型的 ID。其核心思想是：使用 41bit 作为毫秒数，10bit 作为机器的 ID （ 5 个 bit 是数据中心，5 个 bit 的机器 ID ），12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID ），最后还有一个符号位，永远是 0。

该算法实现基本就是二进制操作，如果二进制不熟悉的可以看看我之前写的相关文章：java 二进制相关基础、二进制实战技巧。

这个算法单机每秒内理论上最多可以生成 1000*(2^12)，也就是 409.6 万个 ID，（吼吼，这个得了的快啊）。

java 实现代码基本上就是类似这样的（都差不多，基本就是二进制位操作）：参考： https://www.cnblogs.com/relucent/p/4955340.html

/**
 * Twitter_Snowflake<br>
 * SnowFlake 的结构如下(每部分用-分开):<br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * 1 位标识，由于 long 基本类型在 Java 中是带符号的，最高位是符号位，正数是 0，负数是 1，所以 id 一般是正数，最高位是 0<br>
 * 41 位时间截(毫秒级)，注意，41 位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
 * 得到的值），这里的的开始时间截，一般是我们的 id 生成器开始使用的时间，由我们程序来指定的（如下下面程序 IdWorker 类的 startTime 属性）。41 位的时间截，可以使用 69 年，年 T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * 10 位的数据机器位，可以部署在 1024 个节点，包括 5 位 datacenterId 和 5 位 workerId<br>
 * 12 位序列，毫秒内的计数，12 位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生 4096 个 ID 序号<br>
 * 加起来刚好 64 位，为一个 Long 型。<br>
 * SnowFlake 的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生 ID 碰撞(由数据中心 ID 和机器 ID 作区分)，并且效率较高，经测试，SnowFlake 每秒能够产生 26 万 ID 左右。
 */
public class SnowflakeIdWorker {

    // ==============================Fields===========================================
    /** 开始时间截 (2015-01-01) */
    private final long twepoch = 1420041600000L;

    /** 机器 id 所占的位数 */
    private final long workerIdBits = 5L;

    /** 数据标识 id 所占的位数 */
    private final long datacenterIdBits = 5L;

    /** 支持的最大机器 id，结果是 31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);

    /** 支持的最大数据标识 id，结果是 31 */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

    /** 序列在 id 中占的位数 */
    private final long sequenceBits = 12L;

    /** 机器 ID 向左移 12 位 */
    private final long workerIdShift = sequenceBits;

    /** 数据标识 id 向左移 17 位(12+5) */
    private final long datacenterIdShift = sequenceBits + workerIdBits;

    /** 时间截向左移 22 位(5+5+12) */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    /** 生成序列的掩码，这里为 4095 (0b111111111111=0xfff=4095) */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    /** 工作机器 ID(0~31) */
    private long workerId;

    /** 数据中心 ID(0~31) */
    private long datacenterId;

    /** 毫秒内序列(0~4095) */
    private long sequence = 0L;

    /** 上次生成 ID 的时间截 */
    private long lastTimestamp = -1L;

    //==============================Constructors=====================================
    /**
     * 构造函数
     * @param workerId 工作 ID (0~31)
     * @param datacenterId 数据中心 ID (0~31)
     */
    public SnowflakeIdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    // ==============================Methods==========================================
    /**
     * 获得下一个 ID (该方法是线程安全的)
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();

        //如果当前时间小于上一次 ID 生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        //如果是同一时间生成的，则进行毫秒内序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,获得新的时间戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //时间戳改变，毫秒内序列重置
        else {
            sequence = 0L;
        }

        //上次生成 ID 的时间截
        lastTimestamp = timestamp;

        //移位并通过或运算拼到一起组成 64 位的 ID
        return ((timestamp - twepoch) << timestampLeftShift) //
                | (datacenterId << datacenterIdShift) //
                | (workerId << workerIdShift) //
                | sequence;
    }

    /**
     * 阻塞到下一个毫秒，直到获得新的时间戳
     * @param lastTimestamp 上次生成 ID 的时间截
     * @return 当前时间戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 返回以毫秒为单位的当前时间
     * @return 当前时间(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }

    //==============================Test=============================================
    /** 测试 */
    public static void main(String[] args) {
        SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
        for (int i = 0; i < 1000; i++) {
            long id = idWorker.nextId();
            System.out.println(Long.toBinaryString(id));
            System.out.println(id);
        }
    }
}

优点：

快（哈哈，天下武功唯快不破）。
没有啥依赖，实现也特别简单。
知道原理之后可以根据实际情况调整各各位段，方便灵活。

缺点：

只能趋势递增。（有些也不叫缺点，网上有些如果绝对递增，竞争对手中午下单，第二天在下单即可大概判断该公司的订单量，危险！！！）
依赖机器时间，如果发生回拨会导致可能生成 id 重复。下面重点讨论时间回拨问题。

snowflake 算法时间回拨问题思考

由于存在时间回拨问题，但是他又是那么快和简单，我们思考下是否可以解决呢？零度在网上找了一圈没有发现具体的解决方案，但是找到了一篇美团不错的文章：Leaf ——美团点评分布式 ID 生成系统（ https://tech.meituan.com/MT_Leaf.html ）文章很不错，可惜并没有提到时间回拨如何具体解决。下面看看零度的一些思考：

分析时间回拨产生原因

第一：人物操作，在真实环境一般不会有那个傻逼干这种事情，所以基本可以排除。第二：由于有些业务等需要，机器需要同步时间服务器（在这个过程中可能会存在时间回拨，查了下我们服务器一般在 10ms 以内（ 2 小时同步一次））。

解决方法

由于是分布在各各机器自己上面，如果要几台集中的机器（并且不做时间同步），那么就基本上就不存在回拨可能性了（曲线救国也是救国，哈哈），但是也的确带来了新问题，各各结点需要访问集中机器，要保证性能，百度的 uid-generator 产生就是基于这种情况做的（每次取一批回来，很好的思想，性能也非常不错） https://github.com/baidu/uid-generator。如果到这里你采纳了，基本就没有啥问题了，你就不需要看了，如果你还想看看零度自己的思考可以继续往下看看（零度的思考只是一种思考可能也不一定好，期待你的交流。），uid-generator 我还没有细看，但是看测试报告非常不错，后面有空的确要好好看看。
下面谈谈零度自己的思考，之前也大概和美团 Leaf 作者交流了下，的确零度的这个可以解决一部分问题，但是引入了一些其他问题和依赖。是零度的思考，期待更多的大佬给点建议。

时间问题回拨的解决方法：

当回拨时间小于 15ms，就等时间追上来之后继续生成。
当时间大于 15ms 时间我们通过更换 workid来产生之前都没有产生过的来解决回拨问题。

首先把 workid 的位数进行了调整（ 15 位可以达到 3 万多了，一般够用了） Snowflake 算法稍微调整下位段：

sign(1bit) 固定 1bit 符号标识，即生成的畅途分布式唯一 id 为正数。
delta seconds (38 bits) 当前时间，相对于时间基点"2017-12-21"的增量值，单位：毫秒，最多可支持约 8.716 年
worker id (15 bits) 机器 id，最多可支持约 3.28 万个节点。
sequence (10 bits) 每秒下的并发序列，10 bits，这个算法单机每秒内理论上最多可以生成 1000*(2^10)，也就是100W的 ID，完全能满足业务的需求。

由于服务无状态化关系，所以一般 workid 也并不配置在具体配置文件里面，看看我这篇的思考，为什么需要无状态化。高可用的一些思考和理解，这里我们选择 redis 来进行中央存储（ zk、db ）都是一样的，只要是集中式的就可以。

下面到了关键了：现在我把 3 万多个 workid 放到一个队列中（基于 redis ），由于需要一个集中的地方来管理 workId，每当节点启动时候，（先在本地某个地方看看是否有借鉴弱依赖 zk 本地先保存），如果有那么值就作为 workid，如果不存在，就在队列中取一个当 workid 来使用（队列取走了就没了），当发现时间回拨太多的时候，我们就再去队列取一个来当新的 workid 使用，把刚刚那个使用回拨的情况的 workid 存到队列里面（队列我们每次都是从头取，从尾部进行插入，这样避免刚刚 a 机器使用又被 b 机器获取的可能性）。

有几个问题值得思考：

如果引入了 redis 为啥不用 redis 下发 id ？（查看分布式系统唯一 ID 生成方案汇总会获得答案，我们这里仅仅是用来一致性队列的，能做一致性队列的基本都可以)。
引入 redis 就意味着引入其他第三方的架构，做基础框架最好是不要引用（越简单越好，目前还在学习提高）。
redis 一致性怎么保证？（ redis 挂了怎么办，怎么同步，的确值得商榷。可能会引入会引入很多新的小问题）。

总结

所以选择类似百度的那种做法比较好，集中之后批取，零度的思考虽然思考了，但是从基础组件来看并不是特别合适，但是也算一种思路吧。期待与大佬们的交流。

如果读完觉得有收获的话，欢迎点赞、关注、加公众号 [匠心零度] ，查阅更多精彩历史！！！

19 条回复 • 2018-02-12 11:14:34 +08:00

fenglangjuxu

2018-02-11 19:14:47 +08:00

之前看一个 go 项目,有个地方用到了,不知道是用的人的问题还是,那个 snowflake 库有问题,短时间调用多次会重复.

jiangxinlingdu

2018-02-11 19:16:54 +08:00

@fenglangjuxu 绝逼用的人的问题，这个很强大的只要时钟不会拨那是不会重复的

sw10

2018-02-11 19:39:59 +08:00

之前在微信公众号见过类似的文章，推荐下。
分布式唯一 ID 极简教程： https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247484184&idx=1&sn=e0aed5908e4cd83fdb883e5c6f8d04a5&pass_ticket=lLfy%2B9Ibs6tPHPY2LMmZbh6tQb2hXjITOOPL2BmQtK185COW1jMZSH85qnT0iE%2BJ

由于我们的技术栈是 PHP，最终选的是：donkeyid
GitHub 地址： https://github.com/osgochina/donkeyid

rrfeng

2018-02-11 19:42:44 +08:00

所以引入了一个外部的队列来解决回拨问题？我觉得这种方式并不可取。

相反我有个方案，如果是单机版，那么发现时间回拨之后，worker id 直接自增即可。
如果是分布式版本，那么时间被回拨的节点应该失效，因为还有其他节点可以服务。
如果全部节点时间都被回拨，那么这个问题不需要解决，分布式系统不是用来解决这种问题的。

jiangxinlingdu

2018-02-11 19:46:50 +08:00

@sw10
多谢

honeycomb

2018-02-11 19:47:31 +08:00 via Android

原来是公众号引流

jiangxinlingdu

2018-02-11 19:47:42 +08:00

@rrfeng 到期引入外部队列不好，所以仅仅是思考，你的这个思考也是思考！握手！

jiangxinlingdu

2018-02-11 19:48:15 +08:00

@honeycomb 不是也是分享吧随便导流，记得关注哦哈哈

jiangxinlingdu

2018-02-11 19:49:20 +08:00

@sw10 你们 php 这个咋解决时间回拨问题啊？？？？

dan2001go

2018-02-11 19:55:03 +08:00

这个我用过。挺不错的，自己简单测了一下连续 30 万数据没重复。
应用场景是生成一个无序 ID 做为店铺的惟一标志。缺点是这玩意写到数据库里普通 int 撑不下，所以弄成 bigInt 了。总觉得不太好。不过好在数据量也不大，最后也就几万个店铺。

之后去了另一家公司，看他们生成订单序列的思路也挺有意思的。利用 MySQL 的 AUTO 自增，写了一个 MySQL 自定义函数在那边，去调一下，取到自增的那个 ID，然后拿来用。

@sw10 喷了。你是我以前的同事？？这个 GitHub 是我以前的同事的 GitHub。

gamexg

2018-02-11 20:04:27 +08:00

@rrfeng #4 稍微改点，worker id 最后一位正常永远是 0，如果检测到回拨，则变成 1，等当前时间追上上次的时间在切换回 0。
这样只要不连续回拨就不会出问题，或者扩展为 2 位，就允许连续多次回拨。

sw10

2018-02-11 20:18:09 +08:00

@dan2001go 不是呢，只是我们公司用了 donkeyid 而已。说出来的目的，是希望能给 V2EX 的朋友们一些参考。哈哈哈～

sagaxu

2018-02-11 20:21:21 +08:00

实际上 Linux 系统做时钟同步的时候，使用的是 RFC 5905 里的算法，即使回拨个几秒钟，仍然可以保证 gettimeofday 获取到的时间是单调递增的。往未来调，它也不是瞬间调到未来，而是让时间流逝加速一个百分比。往过去回调，也不是直接倒退，而是让时间流逝变慢。所以只要调整时钟的方式得当，是不存在回拨的问题的。我们的服务器一般会定时做时间同步，基本上时间差是毫秒级的，所以回拨不会影响 ID 生成。

如果要兼容那些不带单调递增时钟的系统，我们可以把这个加速和减速时间的算法加入到 ID 生成器中去。或者简单处理，比如现在是 XXX 毫秒，检测到回拨后，将当前时间戳上 ID 用完，然后一直用完一个就自增时间戳，一直到系统时钟大于当前时间为止。

dan2001go

2018-02-11 20:24:57 +08:00

@sw10 我是看那脸认出来的。。哎，他 Github 维护得比我好多了。

jiangxinlingdu

2018-02-11 20:25:35 +08:00

@sagaxu 不错，一直自增也是不错的选择，的确可以解决，为什么很多没有这么用？是因为效率问题吗？

rrfeng

2018-02-11 20:32:57 +08:00

@sagaxu
如果在 NTP 范围之内是可以的，但是时间抖动任何情况下都可能发生。所以这个容错是必须要处理的。

sagaxu

2018-02-11 20:41:33 +08:00

@jiangxinlingdu 在 Linux 系统上可以不做任何事情就兼容回拨，在非 Linux 系统上，有些项目选择自增至当前时间戳用完然后 sleep 到系统时间追上程序里记录的时间。因为时间回拨往往在一秒以内，大部分就几毫秒，短暂 sleep 不会带来很大问题，引入复杂设计反而容易引入 bug。在做基础设施的时候，有时候选择笨拙而皮实耐用，反而比设计精巧小心实现更为妥当。

sagaxu

2018-02-11 20:47:44 +08:00

@rrfeng twitter 官方自己的做法只是抛个异常并记录一下，sony 开源的变种也没有做很特别的处理。我个人认为在大多数业务场景中，只要检测出来，简单处理即可，不用做的 100%滴水不漏。

lishunli

2018-02-12 11:14:34 +08:00

sequence (10 bits) 每秒下的并发序列，10 bits，这个算法单机每秒内理论上最多可以生成 1000*(2^10)，也就是 100W 的 ID，完全能满足业务的需求。
~~ 这里如果 sequence 真的是每秒的并发序列，那么就不能够*1000，也就是 TPS 大概也就 2^10 （ 1k 左右）的，看了下百度的 uid-generator 也是每秒的序列（好像是 13bit ），还不清楚怎么实现能够单机 600w/s （看代码 uid-generator 确实是每秒中的并发序列）