【分布式】全局唯一ID生成策略

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题，也常常为这个问题而纠结。

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据库的分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。

而生成ID的方法有很多，适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。并且在大型分布式网站架构中，除了需要满足ID生成自身的需求外，还需要ID生成系统可用性极高。下面就介绍一些常见的ID生成策略。

---

01 数据库自增长序列

最常见的方式。利用数据库，全数据库唯一。

• 优点：
  1）简单，代码方便，性能可以接受。
  2）数字ID天然排序，对分页或者需要排序的结果很有帮助。

 

• 缺点：
  1）不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
  2）在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
  3）在性能达不到要求的情况下，比较难于扩展。
  4）如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
  5）分表分库的时候会有麻烦。

 

• 优化方案：
  针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

 

以上方案虽然解决了性能问题，但是也存在很大的局限性：

• 系统水平扩容困难：系统定义好步长之后，增加机器之后调整步长困难。如果要添加机器怎么办？假设现在只有一台机器发号是1,2,3,4,5（步长是1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置得比第一台超过很多，比如14（假设在扩容时间之内第一台不可能发到14），同时设置步长为2，那么这台机器下发的号码都是14以后的偶数。然后摘掉第一台，把ID值保留为奇数，比如7，然后修改第一台的步长为2。让它符合我们定义的号段标准，对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗？貌似还好，现在想象一下如果我们线上有100台机器，这个时候要扩容该怎么做？简直是噩梦。
• 数据库压力大：每次获取一个ID都必须读写一次数据库。当然对于这种问题，也有相应的解决方案，就是每次获取ID时都批量获取一个区间的号段到内存中，用完之后再来获取。数据库的性能提高了几个量级。

---

02 UUID

常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。

UUID是指在一台机器在同一时间中生成的数字在所有机器中都是唯一的。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。

UUID由以下几部分的组合：
（1）当前日期和时间。
（2）时钟序列。
（3）全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

标准的UUID格式为：

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)

以连字号分为五段形式的36个字符，示例：

550e8400-e29b-41d4-a716-446655440000

Java标准类库中已经提供了UUID的API。

UUID.randomUUID()

• 优点：

1）简单，代码方便。

2）生成ID性能非常好，基本不会有性能问题，本地生成，没有网络消耗。

3）全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

• 缺点：

1）没有排序，无法保证趋势递增。

2）UUID往往是使用字符串存储，查询的效率比较低。

3）存储空间比较大，UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用，如果是海量数据库，就需要考虑存储量的问题。

4）信息不安全，基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

5）传输数据量大，并且不可读。

 

不过可以通过UUID变种算法，解决UUID不可读以及UUID无序的问题，具体不表。

---

03 SnowFlake雪花算法

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。生成的是一个64位的二进制正整数，然后转换成10进制的数。64位二进制数由如下部分组成：

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

• 优点

1）简单高效，生成速度快。

2）时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增。

3）灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求。

 

• 缺点

1）依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成。

2）在分布式环境上，每个服务器的时钟不可能完全同步，有时会出现不是全局递增的情况。

 

snowflake Java实现

package com.leon.distributed.algorithm;

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

       long startTime=System.currentTimeMillis();
       for (int i = 0; i < 500000; i++) {
           long id = idWorker.nextId();
           System.out.println(Long.toBinaryString(id));
           System.out.println(id);
       }
       long endTime=System.currentTimeMillis();
       System.out.println("当前程序耗时："+(endTime-startTime)+"ms");
   }
}

snowflake算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数，每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的bit数。

---

04 Redis生成ID

当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

可以使用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

这个，随便负载到哪个机子确定好，未来很难做修改。但是3-5台服务器基本能够满足器上，都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以解决单点故障的问题。

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

 

• 优点：

1）不依赖于数据库，灵活方便，且性能优于数据库。

2）数字ID天然排序，对分页或者需要排序的结果很有帮助。

 

• 缺点：

1）如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。

2）需要编码和配置的工作量比较大。

3）Redis是单线程的，若造成阻塞，则会引发高并发问题，需要处理好集群与主从关系

---

05 其他

• 利用zookeeper生成唯一ID

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

很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper，并且是多步调用API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想。

• MongoDB的ObjectId

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

通过“时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。

MongoDB官方文档 ObjectID https://docs.mongodb.com/manual/reference/method/ObjectId/#description