分布式惟一ID的几种生成方案

时间 2019-11-17

原文原文链接

前言

在互联网的业务系统中，涉及到各类各样的ID，如在支付系统中就会有支付ID、退款ID等。那通常生成ID都有哪些解决方案呢？特别是在复杂的分布式系统业务场景中，咱们应该采用哪一种适合本身的解决方案是十分重要的。下面咱们一一来列举一下，不必定所有适合，这些解决方案仅供你参考，或许对你有用。html

正文

分布式ID的特性

惟一性：确保生成的ID是全网惟一的。
有序递增性：确保生成的ID是对于某个用户或者业务是按必定的数字有序递增的。
高可用性：确保任什么时候候都能正确的生成ID。
带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。

分布式ID的生成方案

1. UUID

算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。java

优势：本地生成，生成简单，性能好，没有高可用风险
缺点：长度过长，存储冗余，且无序不可读，查询效率低

2. 数据库自增ID

使用数据库的id自增策略，如 MySQL 的 auto_increment。而且可使用两台数据库分别设置不一样步长，生成不重复ID的策略来实现高可用。git

优势：数据库生成的ID绝对有序，高可用实现方式简单
缺点：须要独立部署数据库实例，成本高，有性能瓶颈

3. 批量生成ID

一次按需批量生成多个ID，每次生成都须要访问数据库，将数据库修改成最大的ID值，并在内存中记录当前值及最大值。github

优势：避免了每次生成ID都要访问数据库并带来压力，提升性能
缺点：属于本地生成策略，存在单点故障，服务重启形成ID不连续

4. Redis生成ID

Redis的全部命令操做都是单线程的，自己提供像 incr 和 increby 这样的自增原子命令，因此能保证生成的 ID 确定是惟一有序的。web

优势：不依赖于数据库，灵活方便，且性能优于数据库；数字ID自然排序，对分页或者须要排序的结果颇有帮助。算法
缺点：若是系统中没有Redis，还须要引入新的组件，增长系统复杂度；须要编码和配置的工做量比较大。数据库

考虑到单节点的性能瓶颈，可使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台 Redis。能够初始化每台 Redis 的值分别是1, 2, 3, 4, 5，而后步长都是 5。各个 Redis 生成的 ID 为：安全

A：1, 6, 11, 16, 21
B：2, 7, 12, 17, 22
C：3, 8, 13, 18, 23
D：4, 9, 14, 19, 24
E：5, 10, 15, 20, 25
复制代码

随便负载到哪一个机肯定好，将来很难作修改。步长和初始值必定须要事先肯定。使用 Redis 集群也能够方式单点故障的问题。bash

另外，比较适合使用 Redis 来生成天天从0开始的流水号。好比订单号 = 日期 + 当日自增加号。能够天天在 Redis 中生成一个 Key ，使用 INCR 进行累加。架构

5. Twitter的snowflake算法

Twitter 利用 zookeeper 实现了一个全局ID生成的服务 Snowflake：github.com/twitter/sno…

如上图的所示，Twitter 的 Snowflake 算法由下面几部分组成：

1位符号位：

因为 long 类型在 java 中带符号的，最高位为符号位，正数为 0，负数为 1，且实际系统中所使用的ID通常都是正数，因此最高位为 0。

41位时间戳（毫秒级）：

须要注意的是此处的 41 位时间戳并不是存储当前时间的时间戳，而是存储时间戳的差值（当前时间戳 - 起始时间戳），这里的起始时间戳通常是ID生成器开始使用的时间戳，由程序来指定，因此41位毫秒时间戳最多可使用 (1 << 41) / (1000x60x60x24x365) = 69年。

10位数据机器位：

包括5位数据标识位和5位机器标识位，这10位决定了分布式系统中最多能够部署 1 << 10 = 1024 s个节点。超过这个数量，生成的ID就有可能会冲突。

12位毫秒内的序列：

这 12 位计数支持每一个节点每毫秒（同一台机器，同一时刻）最多生成 1 << 12 = 4096个ID

加起来恰好64位，为一个Long型。

优势：高性能，低延迟，按时间有序，通常不会形成ID碰撞
缺点：须要独立的开发和部署，依赖于机器的时钟

简单实现

public class IdWorker {
    /**
     * 起始时间戳 2017-04-01
     */
    private final long epoch = 1491004800000L;
    /**
     * 机器ID所占的位数
     */
    private final long workerIdBits = 5L;
    /**
     * 数据标识ID所占的位数
     */
    private final long dataCenterIdBits = 5L;
    /**
     * 支持的最大机器ID,结果是31
     */
    private final long maxWorkerId = ~(-1L << workerIdBits);
    /**
     * 支持的最大数据标识ID,结果是31
     */
    private final long maxDataCenterId = ~(-1 << 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(12+5+5)位
     */
    private final long timestampShift = sequenceBits + workerIdBits + dataCenterIdBits;
    /**
     * 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095)
     */
    private final long sequenceMask = ~(-1L << sequenceBits);
    /**
     * 数据标识ID（0～31）
     */
    private long dataCenterId;
    /**
     * 机器ID（0～31）
     */
    private long workerId;
    /**
     * 毫秒内序列（0～4095）
     */
    private long sequence;
    /**
     * 上次生成ID的时间戳
     */
    private long lastTimestamp = -1L;

    public IdWorker(long dataCenterId, long workerId) {
        if (dataCenterId > maxDataCenterId || dataCenterId < 0) {
            throw new IllegalArgumentException(String.format("dataCenterId can't be greater than %d or less than 0", maxDataCenterId));
        }
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        this.dataCenterId = dataCenterId;
        this.workerId = workerId;
    }

    /**
     * 得到下一个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 (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,得到新的时间戳
                timestamp = nextMillis(lastTimestamp);
            }
        } else {//时间戳改变，毫秒内序列重置
            sequence = 0L;
        }
        lastTimestamp = timestamp;
        //移位并经过按位或运算拼到一块儿组成64位的ID
        return ((timestamp - epoch) << timestampShift) |
                (dataCenterId << dataCenterIdShift) |
                (workerId << workerIdShift) |
                sequence;
    }

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

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

6. 百度UidGenerator

UidGenerator是百度开源的分布式ID生成器，基于于snowflake算法的实现，看起来感受还行。不过，国内开源的项目维护性真是担心。

具体能够参考官网说明：github.com/baidu/uid-g…

7. 美团Leaf

Leaf 是美团开源的分布式ID生成器，能保证全局惟一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也须要依赖关系数据库、Zookeeper等中间件。

具体能够参考官网说明：tech.meituan.com/MT_Leaf.htm…

小结

这篇文章和你们分享了全局id生成服务的几种经常使用方案，同时对比了各自的优缺点和适用场景。在实际工做中，你们能够结合自身业务和系统架构体系进行合理选型。

做者：陌上轩客连接：https://juejin.im/post/5b3a23746fb9a024e15cad79 来源：掘金著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。