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

时间 2019-11-07

标签分布式惟一 snowflake 算法思考栏目系统架构繁體版

原文原文链接

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

缘起

为何会忽然谈到分布式惟一id呢？缘由是最近在准备使用RocketMQ，看看官网介绍： java

一句话，消息可能会重复，因此消费端须要作幂等。为何消息会重复后续RocketMQ章节进行详细介绍，本节重点不在这里。git

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

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

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

那么该id须要有2个特性：算法

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

若是有方法能够生成全局惟一（那么在局部也必定惟一了），生成分布式惟一id的方法有不少。你们能够看看分布式系统惟一ID生成方案汇总：http://www.cnblogs.com/haoxinyue/p/5208136.html（因为微信不是他的地址都显示不出来，因此把地址贴出来下），这个文章里面提到了不少以及各各的优缺点。本文关注重点是snowflake算法，该算法实现获得的id就知足上面提到的2点。sql

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挂了怎么办，怎么同步，的确值得商榷。可能会引入会引入不少新的小问题）。

总结

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

若是读完以为有收获的话，欢迎点赞、关注、加公众号【匠心零度】，查阅更多精彩历史！！！