做者丨riemann_，原文地址：https://dwz.cn/3IsTKCaNjava
系统惟一ID是咱们在设计一个系统的时候经常会碰见的问题，也经常为这个问题而纠结。生成ID的方法有不少，适应不一样的场景、需求以及性能要求。因此有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。
node
1.数据库自增加序列或字段
最多见的方式。利用数据库，全数据库惟一。git
优势：github
1）简单，代码方便，性能能够接受。web
2）数字ID自然排序，对分页或者须要排序的结果颇有帮助。面试
缺点：redis
1）不一样数据库语法和实现不一样，数据库迁移的时候或多数据库版本支持的时候须要处理。算法
2）在单个数据库或读写分离或一主多从的状况下，只有一个主库能够生成。有单点故障的风险。数据库
3）在性能达不到要求的状况下，比较难于扩展。缓存
4）若是碰见多个系统须要合并或者涉及到数据迁移会至关痛苦。
5）分表分库的时候会有麻烦。
优化方案：
1）针对主库单点，若是有多个Master库，则每一个Master库设置的起始数字不同，步长同样，能够是Master的个数。好比：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就能够有效生成集群中的惟一ID，也能够大大下降ID生成数据库操做的负载。
2. UUID
常见的方式。能够利用数据库也能够利用程序生成，通常来讲全球惟一。
优势：
1）简单，代码方便。
2）生成ID性能很是好，基本不会有性能问题。
3）全球惟一，在碰见数据迁移，系统数据合并，或者数据库变动等状况下，能够从容应对。
缺点：
1）没有排序，没法保证趋势递增。
2）UUID每每是使用字符串存储，查询的效率比较低。
3）存储空间比较大，若是是海量数据库，就须要考虑存储量的问题。
4）传输数据量大
5）不可读。
3. UUID的变种
1）为了解决UUID不可读，可使用UUID to Int64的方法。
/// <summary>/// 根据GUID获取惟一数字序列/// </summary>public static long GuidToInt64(){ byte[] bytes = Guid.NewGuid().ToByteArray(); return BitConverter.ToInt64(bytes, 0);}
2）为了解决UUID无序的问题，NHibernate在其主键生成方式中提供了Comb算法（combined guid/timestamp）。保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime）。
/// <summary>/// Generate a new <see cref="Guid"/> using the comb algorithm./// </summary>private Guid GenerateComb(){ byte[] guidArray = Guid.NewGuid().ToByteArray(); DateTime baseDate = new DateTime(1900, 1, 1); DateTime now = DateTime.Now; // Get the days and milliseconds which will be used to build //the byte string TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks); TimeSpan msecs = now.TimeOfDay; // Convert to a byte array // Note that SQL Server is accurate to 1/300th of a // millisecond so we divide by 3.333333 byte[] daysArray = BitConverter.GetBytes(days.Days); byte[] msecsArray = BitConverter.GetBytes((long) (msecs.TotalMilliseconds / 3.333333)); // Reverse the bytes to match SQL Servers ordering Array.Reverse(daysArray); Array.Reverse(msecsArray); // Copy the bytes into the guid Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2); Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4); return new Guid(guidArray);}
用上面的算法测试一下，获得以下的结果：做为比较，前面3个是使用COMB算法得出的结果，最后12个字符串是时间序（统一毫秒生成的3个UUID），过段时间若是再次生成，则12个字符串会比图示的要大。后面3个是直接生成的GUID。
若是想把时间序放在前面，能够生成后改变12个字符串的位置，也能够修改算法类的最后两个Array.Copy。
4. 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）须要编码和配置的工做量比较大。
5.Twitter的snowflake算法
snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit做为毫秒数，10bit做为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit做为毫秒内的流水号（意味着每一个节点在每毫秒能够产生 4096 个 ID），最后还有一个符号位，永远是0。
/** * 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); } }}
snowflake算法能够根据自身项目的须要进行必定的修改。好比估算将来的数据中心个数，每一个数据中心的机器数以及统一毫秒能够能的并发数来调整在算法中所须要的bit数。
优势：
1）不依赖于数据库，灵活方便，且性能优于数据库。
2）ID按照时间在单机上是递增的。
缺点：
1）在单机上是递增的，可是因为涉及到分布式环境，每台机器上的时钟不可能彻底同步，也许有时候也会出现不是全局递增的状况。
6.利用zookeeper生成惟一ID
zookeeper主要经过其znode数据版原本生成序列号，能够生成32位和64位的数据版本号，客户端可使用这个版本号来做为惟一的序列号。不多会使用zookeeper来生成惟一ID。主要是因为须要依赖zookeeper，而且是多步调用API，若是在竞争较大的状况下，须要考虑使用分布式锁。所以，性能在高并发的分布式环境下，也不甚理想。
7.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。
实现的源码能够到MongoDB官方网站下载。
8.美团点评分布式ID生成系统
Leaf 最先期需求是各个业务线的订单ID生成需求。在美团早期，有的业务直接经过DB自增的方式生成ID，有的业务经过redis缓存来生成ID，也有的业务直接用UUID这种方式来生成ID。以上的方式各自有各自的问题，所以咱们决定实现一套分布式ID生成服务来知足需求。具体Leaf 设计文档见： leaf 美团分布式ID生成服务
github地址：
https://github.com/Meituan-Dianping/Leaf
推荐阅读
本文分享自微信公众号 - 爱编码（ilovecode）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。