本文分析了在分布式系统中生成全局唯一ID的需求，包括全局唯一、趋势递增和非连续性。对比了几种常见方案：UUID因其长度过长而不适合；雪花算法基于时间戳、工作ID和序列号生成，性能高但依赖时钟；MySQL的自增ID简单但存在单点故障；美团的Leaf服务结合了MySQL和雪花算法的优点，但仍有数据库依赖。每种方案都有其优缺点，需根据实际需求选择。
1 背景
目前的系统中，有很多业务需要对数据进行唯一标识(订单号、用户券码、事件id等)，系统对id号往往有以下几点要求：
全局唯一。不能出现重复的id号，这是基本的要求
趋势递增。为了保证mysql聚集索引性能，尽量保证有序性
非连续。数据不能是连续的，例如券的id是连续的，有可能被恶意请求领券；并且可以让外界知道一天的数据量
2 方案
2.1 uuid
uuid是大部分人第一个接触的唯一id生成方式。共包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符
优点：
性能高，本地直接生成，没有网络消耗
缺点：
uuid过长，作为主键性能太差
生成为字符串，很多场景需要使用long类型
2.2 雪花算法
image.png
1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。
41bit-时间戳，用来记录时间戳，毫秒级。
10bit-工作机器id，用来记录工作机器id。
12bit-序列号，序列号，用来记录同毫秒内产生的不同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());
}
}
}
优点：
毫秒数在高位，保证了递增趋势
不依赖第三方，性能很高
缺点：
强依赖于时钟，如果时钟回拨会造成重复
2.3 MySQL
给数据库主键设置 auto_increment_increment保证自增，每次需要获取唯一id时访问数据库即可
优点：
简单，不需要引入额外的技术
缺点：
数据库有单点故障，数据库宕机导致获取分布式id的服务不可用
每次获取都需要访问数据库，容易产生性能瓶颈
2.4 leaf
leaf是美团自研的分布式id服务，有Leaf-segment和Leaf-snowflake两种类型。分别弥补了MySQL和snowflake各自的缺点
2.4.1 Leaf-segment
Leaf-segment在mysql的基础上，解决了每次获取都需要访问mysql的弊端。改为每次获取一段数据，大大减少了访问数据库的频率。
image.png
同时，为了解决leaf服务同时访问数据库而造成的数据库压力过大，对 Leaf-segment做了些优化，采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。
除此之外，Leaf-segment采用了类似于拥塞控制的思路，根据服务获取段的时间差，来控制步长。时间差短，步长增加；时间差长，减少步长。但是增大或减少都不会超过设定的阈值。
优点：
leaf服务有一段缓存，即使数据库不可用，在一段时间内也可以提供服务
缺点：
DB宕机会造成整个系统不可用。
id不够随机
2.4.1 Leaf-snowflake
Leaf-snowflake是在snowflake的基础上进行了改进，避免的时间回拨造成的id重复。为了方便管理和配置，使用zk管理和分配workId，同时服务启动后将workId进行本地缓存，从而保证弱依赖zk。
启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过(是否有该顺序子节点)。
如果有注册过直接取回自己的workerID(zk顺序节点生成的int类型ID号)，启动服务。
如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。
解决时钟问题：
image.png
思路是保证zk上保存的时间是相对准确的，和zk上的时间进行对比，如果超过阈值就失败并报警。保证了时间回拨不会造成影响
如果节点是新的，则和其他节点的平均时间进行对比，如果超过阈值则失败
如果节点是旧的，则和该节点上次的时间进行比较，如果小于了上次的时间，则说明发生了时间回拨，失败并报警。
每隔3秒上传自己的时间到zk
扫一扫
580
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
