分布式集群下如何做到唯一序列号

优质博文：IT-BLOG-CN

分布式架构下，生成唯一序列号是设计系统常常会遇到的一个问题。例如，数据库使用分库分表的时候，当分成若干个sharding表后，如何能够快速拿到一个唯一序列号，是经常遇到的问题。实现思路如下：

【1】数据库自增长序列或字段：全数据库唯一。
【优点】：简单，代码方便，性能可以接受。数字ID天然排序，对分页后者需要排序的结果很有帮组。适合小应用，无需分表，无高并发性能要求。
【缺点】：不同数据库实现不同，在水平分表时，使用自增ID时可能会出现ID冲突。同时在高并发的情况下需要使用事务。在性能达不到要求的情况下，比较难于扩展。如果多个系统需要合并或者设计到数据迁移会相当痛苦。
【优化】：针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。比如：Master1生成的是1，4，7，10，Master2生成的是2,5,8,11，Master3生成的是3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

【2】UUID：常见的方式。可以利用数据库也可以利用程序生成32位的16进制格式的字符串，唯一性很高。
【优点】：简单，方便，生产ID性能非常好且全球基本唯一，在数据迁移和系统后期合并，或数据库变更等情况下都可应对。
【缺点】：没有排序，无法保证趋势递增。UUID使用字符串存储，查询效率低。存储空间较大，如果数据海量就绪考虑存储量问题，传输数据量大。

UUID是一种标准的128位标识符，几乎可以保证全局唯一。Java中可以使用java.util.UUID来生成：

import java.util.UUID;public class UniqueIDGenerator {public static String generateUUID() {return UUID.randomUUID().toString();}
}

【3】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进行累加。
【优点】：不依赖于数据库，灵活方便，且性能优于数据库。数字ID天然排序，对分页或者需要排序的结果很有帮助。
【缺点】：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。需要编码和配置的工作量比较大。

使用Redis的原子操作，如INCR命令，可以生成全局唯一的序列号。Redis的高性能和分布式特性使其成为一个不错的选择

import redis.clients.jedis.Jedis;public class RedisIdGenerator {private Jedis jedis;private String key;public RedisIdGenerator(String redisHost, int redisPort, String key) {this.jedis = new Jedis(redisHost, redisPort);this.key = key;}public long nextId() {return jedis.incr(key);}
}

【4】Twitter（推特） 的snowflake算法： twitter在把存储系统从MySQL迁移到Cassandra（一套开源分布式NoSQL数据库系统）的过程中由于Cassandra没有顺序ID生成机制，于是自己开发了一套全局唯一ID生成服务：Snowflake。
 ● 41位的时间序列（精确到毫秒，41位的长度可以使用69年）
 ● 10位的机器标识（10位的长度最多支持部署1024个节点）
 ● 12位的计数顺序号（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号） 最高位是符号位，始终为0

Snowflake的结构如下(每部分用-分开)： 一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试snowflake每秒能够产生26万个ID。
【优点】：高性能，低延迟；独立的应用；按时间有序。
【缺点】：需要独立的开发和部署。在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。

Java实现的Snowflake算法示例：

public class SnowflakeIdGenerator {private final long twepoch = 1288834974657L;private final long workerIdBits = 5L;private final long datacenterIdBits = 5L;private final long maxWorkerId = -1L ^ (-1L << workerIdBits);private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);private final long sequenceBits = 12L;private final long workerIdShift = sequenceBits;private final long datacenterIdShift = sequenceBits + workerIdBits;private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;private final long sequenceMask = -1L ^ (-1L << sequenceBits);private long workerId;private long datacenterId;private long sequence = 0L;private long lastTimestamp = -1L;public SnowflakeIdGenerator(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;}public synchronized long nextId() {long timestamp = timeGen();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;}lastTimestamp = timestamp;return ((timestamp - twepoch) << timestampLeftShift) |(datacenterId << datacenterIdShift) |(workerId << workerIdShift) |sequence;}protected long tilNextMillis(long lastTimestamp) {long timestamp = timeGen();while (timestamp <= lastTimestamp) {timestamp = timeGen();}return timestamp;}protected long timeGen() {return System.currentTimeMillis();}
}

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

前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5个字节组合起来，提供了秒级别的唯一性。由于时间戳在前，这意味着ObjectId大致会按照插入的顺序排列。这对于某些方面很有用，如将其作为索引提高效率。这4个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId获取这个信息。

接下来的3字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId，不产生冲突。

为了确保在同一台机器上并发的多个进程产生的ObjectId是唯一的，接下来的两字节来自产生ObjectId的进程标识符PID。
前9字节保证了同一秒钟不同机器不同进程产生的ObjectId是唯一的。后3字节就是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId也是不一样的。同一秒钟最多允许每个进程拥有2563（16 777 216）个不同的ObjectId。

【6】Zookeeper： Zookeeper可以用来实现分布式唯一ID生成器。通过创建顺序节点，可以确保每个节点的名称是唯一且递增的。

【7】其他一些方案： 比如京东淘宝等电商的订单号生成。因为订单号和用户id在业务上的区别，订单号尽可能要多些冗余的业务信息，比如：滴滴：时间+起点编号+车牌号 淘宝订单：时间戳+用户ID 其他电商：时间戳+下单渠道+用户ID，有的会加上订单第一个商品的ID。而用户ID，则要求含义简单明了，包含注册渠道即可，尽量短。