六大全局唯一ID生成算法策略，效率对比。 总有一款是你的菜

分布式ID的要求

• UNIQ 唯一性：ID，ID 要的就是唯一
• HP 高性能：生成ID的服务，不能成为瓶颈
• HA 高可用：保证高可用，如果ID是订单ID，突然ID服务宕机，影响全局交易就不好了
• 趋势：递增还是随机，看场景需要

知道了基本要求，下面开始介绍各种策略，并分析一下他们的是否达到了这些要求。

---

1:UUID

uuid例子：f1c09159-97c3-4ac1-8cb1-2d820a8eeb05

经过计算，每秒生成10亿个UUID，100年不间断，有50%的可能产生一个冲突
UUID的碰撞只存在理论上的可能，现实中可以忽略不计。

我们来看下性能：单线程1秒 百万量级。

因为是全局唯一，所以我们常常用来做分布式锁的唯一标识，保证获得锁和释放锁的是同一个人。

唯一性：满足
高性能：满足
高可用：满足
趋势：随机

---

2:Redis incr

redis作为单线程的nosql系统。
使用incr就高性能的生成唯一的单调递增ID。

唯一性：基本满足（依赖可用性）
高性能：基本满足
高可用：不满足，存于内存，要考虑持久化和容灾。集群模式下重连还要进行主从复制，等待时间比较长。
趋势：单调递增

---

3:Snowflake雪花算法

下面说一说大名鼎鼎的Twitter的雪花算法。
算法结果是一个长整型 Long
大佬们惯用的 位存储转基本类型。

基本原理如下图，一眼就描述清楚了。

• 0位 符号位：0 正数
• 1~41位：毫秒时间戳，减一个固定开始时间，可以延长使用时间
• 42~51位：业务ID
• 52~64位：序列号 自增 2^12 = 4096

每毫秒1024个业务，每个业务能容纳4096个ID。
生成效率，30W/s

唯一性：满足
高性能：满足
高可用：满足
趋势：趋势递增

当然这是一种思路
在企业开发中，可以在企业开发中借鉴一下
比如我们生成订单号就是类似的思路：630558772926921027。
出于保密，我就不具体解读了。

雪花就没毛病了嘛？大部分场景其实是的。不过有两个问题，还是需要考虑：

1. 每毫秒4096，还是可能成为瓶颈的
2. 雪花ID是长整型，直接用来做SQL主键，也是比较浪费空间的。
3. 依赖机器时间，可能会有实现回拨

---

4: AUTO_INCREMENT数据库自增

直接使用DB的AUTO_INCREMENT。就能得到递增的ID。

唯一性：满足
高性能：IO瓶颈哦
高可用：单机问题
趋势：单调递增

纯粹个人玩玩可以。线上还要针对性能和可用性进行优化，所以就引入集群模式。

---

5：数据库集群模式

要数据库的高性能高可用，肯定要考虑集群。

有了多态机器，就需要每个机器单独负责生成号码。
我们使用 初始值offset 加 步长increment

来看配置

MySQL_1 配置：
set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 3;  -- 步长

MySQL_2 配置：
set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 3;  -- 步长

MySQL_3 配置：
set @@auto_increment_offset = 3;     -- 起始值
set @@auto_increment_increment = 3;  -- 步长

完美解决。
Mysql1生成：1，4，7，10……
Mysql2生成：2，5，8，11……
Mysql3生成：3，6，9，12……

但是发现问题来了。 这里的步长就等于机器的数量。
未来如果要扩容就非常困难了。。。

唯一性：满足
高性能：满足
高可用：集群高可用
趋势：趋势递增

缺点：

1. 无法扩容。定好步长和初始值后，就凉了。再次扩容，一般需要停滞服务，并产生号段空洞。
2. 成本高

为了解决性能瓶颈和处理扩容问题

---

6：Segment 号段模式

集群模式，每个ID和数据库交互一次。
而号段模式，借鉴单次步长step，就是一次SQL交互取出的ID代表了一个号段。
如id=1，step=1000. 代表数字[1,1000].
获去1个ID的读写数据库的频率，从1减小到了1/step。

先看例子，我直接使用美团的id生成器Leaf来说明。
先上表。
DB数据

CREATE DATABASE leaf
CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '', -- your biz unique name
  `max_id` bigint(20) NOT NULL DEFAULT '1', // 当前被使用的最大ID
  `step` int(11) NOT NULL, // 单步步长
  `description` varchar(256)  DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')

使用leaf-segment-test2 生效ID的效果

可以看到 max_id = 201 而 step=100时。
此时内存中（segment对象）存储了[101,200] 共100个ID。 进行自增的发号

这样每100个号码才IO一次。 瓶颈解决

同时Leaf为了防止IO获取号段时，导致的服务不可用，采用提前加载的方式处理。称为双buffer优化

当取到309时

db效果

再取几个

db效果

可以看到这里提前开辟了号段。

	// 关键的判断： 剩余 < 总数的90%（发了10%，就会去开辟新号段）。 
	segment.getIdle() < 0.9 * segment.getStep()

取得的新号段，会在Buffer中存储，可以看到源码中，Segment是数组。通过通过维护好currentPos实现提前号段的buffer~ 女少！

唯一性：满足
高性能：满足
高可用：集群高可用
趋势：趋势递增

同时拓展只需新增biz_tag 也比较方便。 我们公司交易的分库分表就是采用Segment来实现的。

TIPS：第三方框架

美团Leaf：世界上没有两片完全相同的树叶。
https://github.com/Meituan-Dianping/Leaf/blob/feature/spring-boot-starter/README_CN.md

百度：https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

其实技术选型不是找到最极致的，而是找到最合适的。
所以公司层面，一般都会定制自己的分布式ID来满足相关的业务需求。

溜了溜了