分布式系统唯一ID方案

初极狭，才通人。复行数十步，豁然开朗

系统唯一ID是我们在工作中经常会遇到的, 不管从事什么行业都会用到, 耳熟能详的有根据数据库的自增ID, 或者UUID等等, 下面我们大概总结一下

数据库自增长ID

这是一种最常见的方式, 就是依靠数据库的自增长, 任何数据库都可以, 具体实现方式, 我们简单列举几个

Mysql

//建表设置id为主键并自增
create table users(id int auto_increment primary key not null,name varchar(10)); 
//修改表id字段类型为int型+自增属性
alter table 表名 change id id int auto_increment;

SqlServer

create table users(id int identity(1,1) primary key not null,name varchar(10));

Oracle

create sequence users_id_sql increment by 1 start with 1;//users_id_sql为序列名

• 优点
  • 实现比较简单, 代码方便, 性能上总的来说也可以接受
  • 并且生成的ID是数字类型的, 对于查询效率来说是比较友好的, 并且所占的空间也比较少
• 缺点
  • 在单点数据库或者主备模式的情况下, 只有一个主库可以生成ID, 存在单点风险
  • 一旦出现了性能问题, 这种方案比较难扩展
  • 不同的数据库的语法或者实现多少会有差异性, 一旦数据库需要迁移不同版本的时候比较麻烦
• 优化
  • 这方式可以优化的场合就是针对主库单点的情况, 首先要避免单点的问题, 然后当存在做个Master库的时候, 针对于每个库设置起始数字不一样, 当时步长是一样的, 例如一个Master生成1, 3, 5。Master2生成2, 4, 6。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

UUID

UUID 是指Universally Unique Identifier，翻译为中文是通用唯一识别码，UUID 的目的是让分布式系统中的所有元素都能有唯一的识别信息。UUID 是由一组32位数的16进制数字所构成，是故 UUID 理论上的总数为1632=2128，约等于3.4 x 10123。也就是说若每纳秒产生1百万个 UUID，要花100亿年才会将所有 UUID 用完。

格式

UUID 的十六个八位字节被表示为 32个十六进制数字，以连字号分隔的五组来显示，形式为 8-4-4-4-12，总共有 36个字符（即三十二个英数字母和四个连字号）。例如：
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

数字M的四位表示 UUID 版本，当前规范有5个版本，M可选值为1, 2, 3, 4, 5 ；

数字N的一至四个最高有效位表示 UUID 变体( variant )，有固定的两位10xx因此只可能取值8, 9, a, b

当前规范的UUID总共有5个版本, 而且上面我们说到了不同版本是通过M进行标示

• version 1 date-time & MAC address 基于时间的UUID
• version 2 date-time & group/user id DCE安全的UUID
• version 3 MD5 hash & namespace 基于名字的UUID（MD5）
• version 4 pseudo-random number 随机UUID
• version 5 SHA-1 hash & namespace 基于名字的UUID（SHA1）

从不同版本的描述也能看出来一些,
版本1和2 比较适用于于分布式环境, 具有高度的唯一性
版本3和5 比较适用于在一定范围内保证唯一, 需要或可能会重复生成UUID的环境下.
版本4 是通过随机数来生成, 在JAVA中是通过伪随机数生成的一定程度上避免了重复的概率, 但是出现碰撞的概率也是存在的.

• 优点
  • 可以利用数据库也可以利用程序生成, 实现简单, 代码方便.
  • 生成ID的性能比较好, 基本不会有性能问题
  • 号称全球唯一, 在遇到数据迁移, 系统数据合并, 或者数据变更的情况下, 可以从容应对
• 缺点
  • 是一个字符串, 不能进行排序, 当数据量比较大的时候, 查询效率有问题
  • UUID存储空间比较大, 如果遇到数据量比较到, 存储也会有问题

Redis生成ID

当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5, 生成的ID为

• 1,6,11,16,21

• 2,7,12,17,22

• 3,8,13,18,23

• 4,9,14,19,24

• 5,10,15,20,25

• 优点

  • 依赖于Redis, 性能比较高
  • 数字ID天然排序，对分页或者需要排序的结果很有帮助。

• 缺点

  • 如果系统中没有采用Redis作为缓存的话, 需要额外引入Redis, 增加了复杂度
  • 需要编码和配置的工作量比较大

Snowflake算法

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

1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。

41bit-时间戳，用来记录时间戳，毫秒级。

• 41位可以表示个数字，
• 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至 ，减1是因为可表示的数值范围是从0开始算的，而不是1。
• 也就是说41位可以表示个毫秒的值，转化成单位年则是年

10bit-工作机器id，用来记录工作机器id。

• 可以部署在个节点，包括5位datacenterId和5位workerId
• 5位（bit）可以表示的最大正整数是，即可以用0、1、2、3、…31这32个数字，来表示不同的datecenterId或workerId

12bit-序列号，序列号，用来记录同毫秒内产生的不同id。

• 12位（bit）可以表示的最大正整数是，即可以用0、1、2、3、…4094这4095个数字，来表示同一机器同一时间截（毫秒)内产生的4095个ID序号。

由于在Java中64bit的整数是long类型，所以在Java中SnowFlake算法生成的id就是long来存储的以上是该算法标准的一个格式, 在我们的实际应用中还可以根据自己的业务需求来调整各个模块所占用的位数.

public class IdWorker{

    //下面两个每个5位，加起来就是10位的工作机器id
    private long workerId;    //工作id
    private long datacenterId;   //数据id
    //12位的序列号
    private long sequence;

    public IdWorker(long workerId, long datacenterId, long sequence){
        // sanity check for workerId
        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));
        }
        System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
                timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);

        this.workerId = workerId;
        this.datacenterId = datacenterId;
        this.sequence = sequence;
    }

    //初始时间戳
    private long twepoch = 1288834974657L;

    //长度为5位
    private long workerIdBits = 5L;
    private long datacenterIdBits = 5L;
    //最大值
    private long maxWorkerId = -1L ^ (-1L << workerIdBits);
    private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    //序列号id长度
    private long sequenceBits = 12L;
    //序列号最大值
    private long sequenceMask = -1L ^ (-1L << sequenceBits);
    
    //工作id需要左移的位数，12位
    private long workerIdShift = sequenceBits;
   //数据id需要左移位数 12+5=17位
    private long datacenterIdShift = sequenceBits + workerIdBits;
    //时间戳需要左移位数 12+5+5=22位
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    
    //上次时间戳，初始值为负数
    private long lastTimestamp = -1L;

    public long getWorkerId(){
        return workerId;
    }

    public long getDatacenterId(){
        return datacenterId;
    }

    public long getTimestamp(){
        return System.currentTimeMillis();
    }

     //下一个ID生成算法
    public synchronized long nextId() {
        long timestamp = timeGen();

        //获取当前时间戳如果小于上次时间戳，则表示时间戳获取出现异常
        if (timestamp < lastTimestamp) {
            System.err.printf("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
            throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds",
                    lastTimestamp - timestamp));
        }

        //获取当前时间戳如果等于上次时间戳（同一毫秒内），则在序列号加一；否则序列号赋值为0，从0开始。
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0;
        }
        
        //将上次时间戳值刷新
        lastTimestamp = timestamp;

        /**
          * 返回结果：
          * (timestamp - twepoch) << timestampLeftShift) 表示将时间戳减去初始时间戳，再左移相应位数
          * (datacenterId << datacenterIdShift) 表示将数据id左移相应位数
          * (workerId << workerIdShift) 表示将工作id左移相应位数
          * | 是按位或运算符，例如：x | y，只有当x，y都为0的时候结果才为0，其它情况结果都为1。
          * 因为个部分只有相应位上的值有意义，其它位上都是0，所以将各部分的值进行 | 运算就能得到最终拼接好的id
        */
        return ((timestamp - twepoch) << timestampLeftShift) |
                (datacenterId << datacenterIdShift) |
                (workerId << workerIdShift) |
                sequence;
    }

    //获取时间戳，并与上次时间戳比较
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    //获取系统时间戳
    private long timeGen(){
        return System.currentTimeMillis();
    }

    //---------------测试---------------
    public static void main(String[] args) {
        IdWorker worker = new IdWorker(1,1,1);
        for (int i = 0; i < 30; i++) {
            System.out.println(worker.nextId());
        }
    }
}

• 优点
  • 不依赖于数据库，灵活方便，且性能优于数据库。
  • ID按照时间在单机上是递增的。
  • 根据自身项目的需要进行一定的修改
• 缺点
  • 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。

其他

以上我们介绍了几种常见的ID生成方案, 其实还有几种方案, 例如微软基于UUID实现的GUID,

Zookeeper实现zookeeper主要通过其znode数据版本来生成序列号，可以生成32位和64位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。

通过一些NoSql比如MongoDB中的默认ObjectId(""), 和snowflake算法类似。它设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。