分布式全局ID生成方案汇总和对比
1. 为什么需要全局ID
当业务量不大的时候，单库单表使用数据库自增ID就可以解决绝不多数问题，可是随着业务的增长，势必涉及到分库分表，此时使用数据库的主键ID就会出现问题，因此我们需要一个全局唯一的ID。
2. 全局ID的要求
- 全局唯一
- 支持高并发
- 能够体现一定属性
- 高可靠，容错单点故障
- 高性能
3. 生成方案
- UUID
- 数据库自增ID
- 号段模式
- Redis
- twitter 雪花算法（SnowFlake）
- 滴滴出品（TinyID）
- 百度 （Uidgenerator）
- 美团（Leaf）
1. 2. UUID
常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。
优点：
- 简单，代码方便。
- 生成ID性能非常好，基本不会有性能问题。
- 全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。
缺点：
- 没有排序，无法保证趋势递增。
- UUID往往是使用字符串存储，查询的效率比较低。
- 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
- 传输数据量大。
- 不可读。
2. 数据库自增ID
可以维护一个单独的表用于生成分布式ID
CREATE TABLE SEQ.SEQUENCE (
id bigint(20) unsigned NOT NULL auto_increment
PRIMARY KEY (id),
) ENGINE=MyISAM;
复制代码优点：
- 简单
- 数值型，趋势递增
缺点：
- 数据库压力大，效率低，DB可能存在宕机风险
- 宕机风险的解决办法是使用集群模式，设置不同库表的起始值和步长，但是这种模式扩容困难
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步长
...
复制代码
3. 基于数据库的号段模式
号段模式是当下分布式ID生成器的主流实现方式之一，号段模式可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。表结构如下：
CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的步长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号，乐观锁，，每次都更新version，保证并发时数据的正确性',
PRIMARY KEY (`id`)
)
复制代码等这批号段ID用完，再次向数据库申请新号段，对max_id字段做一次update操作，update max_id= max_id + step，update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]
update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX
复制代码4. 基于redis
Redis实现了一个原子操作INCR和INCRBY实现递增的操作。当使用数据库性能不够时，可以采用Redis来代替，同时使用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
复制代码优点
- 不依赖于数据库，灵活方便，且性能优于数据库。
- 数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：
- 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
- 需要编码和配置的工作量比较大。这个都不是最大的问题。
- redis数据持久化问题
5. snowflake方案
snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。
这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等。
其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号，最后还有一个符号位，永远是0。
比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：
整个结构是64位，所以我们在Java中可以使用long来进行存储。 该算法实现基本就是二进制操作,单机每秒内理论上最多可以生成1024*(2^12)，也就是409.6万个ID(1024 X 4096 = 4194304)
优点：
整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
- 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
- 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
- 可以根据自身业务特性分配bit位，非常灵活。
缺点：
- 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
- 针对此，美团做出了改进：github.com/Meituan-Dia…
package com.example.demo.service;
/**
* @Author: dawang
* @Desc:
* @Date: 20:51 2020/2/16
*/
public class SnowFlake {
// ==============================Fields==================
/**
* 开始时间截 (2019-08-06)
*/
private final long START_TIMESTAMP = 1565020800000L;
/**
* 机器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)
*/
SnowFlake(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 - START_TIMESTAMP) << 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) {
SnowFlake idWorker = new SnowFlake(0, 0);
for (int i = 0; i < 1000; i++) {
long id = idWorker.nextId();
System.out.println(Long.toBinaryString(id));
System.out.println(id);
}
}
}
复制代码6. 百度（uid-generator）
uid-generator是基于Snowflake算法， 项目地址：github.com/baidu/uid-g…
粉丝福利
福利一:
长按扫码关注下方二维码，回复「后端爱码士」四个字，即可领取后端技术资料包（由号主（阿里p7）和另外四位BAT等互联网大厂技术专家级朋友倾力总结，包括java并发，mysql，redis，kafka，zookeeper原理以及面试套路等）
福利二:
长按扫描下方二维码，加号主微信，然后将本文转发朋友圈，攒够30个赞，截图反馈给号主，就能获得如下福利：
-
获邀进入号主创建的互联网大厂面试讨论群。
-
以6折优惠价（原价1499元/个）获得笔者一对一收徒第三期的名额（前提是需要有一定的基础，需要通过考核），先到先得，每期5个名额，前两期10名学徒全部收获大厂offer，平均月薪28k以上。
-
阿里，腾讯，美团，滴滴，字节，百度等大厂内推机会。
