分布式ID

一、背景

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；

此时一个能够生成全局唯一ID的系统是非常必要的。

那业务系统对ID的要求有哪些呢？

  1. 全局唯一：最基本要求。
  2. 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
  3. 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
  4. 信息安全：如果ID连续，容易被爬取信息、甚至泄漏业务单量等关键信息。

上述123对应三类不同的场景，3和4需求还是互斥的，无法使用同一个方案满足。

同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高。

由此总结下一个ID生成系统应该做到如下几点：

  1. 平均延迟和TP999延迟都要尽可能低；
  2. 可用性5个9；
  3. 高QPS。

三、常见生成方案

数据库

  1. 主键自增：直接使用主键
  2. 号段：乐观锁方式，一次申请一批id，在单机内存中分配。
  3. redis原子自增：incr

优点：

  1. 实现简单
  2. ID有序递增
  3. ID短，存储成本低

缺点：

  1. 信息安全
  2. 强依赖DB，DB异常时系统不可用。配置主从复制可以尽可能增加可用性，但数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。
  3. 发号性能瓶颈在单台MySQL的读写性能。

算法

UUID

1
2
java.util.UUID.randomUUID()
// eg: 94208c59-5a3f-4d8c-a780-d220f7ada4e0

优点：

  1. 高性能

缺点：

  1. 存储成本高（128位
  2. 不安全：造成机器MAC地址泄漏
  3. 无序
  4. 需要解决重复ID问题：机器时间不对时，可能产生重复ID

类Snowflake

大致来说是一种以划分命名空间来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等。

如snowflake如下

Snowflake

sign(1bit):符号位（标识正负），始终为 0，代表生成的 ID 为正数。

timestamp (41 bits):一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年）

datacenter id + worker id (10 bits):一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整）。这样就可以区分不同集群/机房的节点。

sequence (12 bits):一共 12 位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个 唯一 ID。

优点：

  1. 毫秒在高位，自增序列在低位，趋势递增。
  2. 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
  3. 可以根据自身业务特性分配bit位，非常灵活。

缺点：

  1. 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

开源框架

Leaf （美团

实现了号段、类Snowflake两种方案。

Leaf-segment方案

每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。

各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。

image-20240406104656314

大致架构如下

img

test_tag在第一台Leaf机器上是1-1000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是3001-4000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000，更新号段的SQL语句如下：

1
2
3
4
Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit

这种模式有以下优缺点：

优点：

  • Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
  • ID号码是趋势递增的8byte的64位数字，满足上述数据库存储的主键要求。
  • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
  • 可以自定义max_id的大小，非常方便业务从原有的ID方式上迁移过来。

缺点：

  • ID号码不够随机，能够泄露发号数量的信息，不太安全。
  • TP999数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，tg999数据会出现偶尔的尖刺。
  • DB宕机会造成整个系统不可用。

双buffer优化

对于第二个缺点，leaf-segment做了一些优化：

Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。

为此，我们希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标。详细实现如下图所示：

img

采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。

  • 每个biz-tag都有消费速度监控，通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
  • 每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。
Leaf-snowflake方案

Leaf-segment方案可以生成趋势递增的ID，同时ID号是可计算的，不适用于订单ID生成场景，比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，我们提供了 Leaf-snowflake方案。

img

Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的：

  1. 启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
  2. 如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
  3. 如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。

img

弱依赖ZK

在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题，恰好机器出现问题需要重启时，能保证服务能够正常启动。这样做到了对三方组件的弱依赖。一定程度上提高了SLA。

解决时钟问题

和zk交互，启动时、启动后每隔一段时间上报时间确认当前没有偏离很远。

要么在时钟回拨的时候直接不提供服务直接返回ERROR_CODE，等时钟追上即可。或者做一层重试，然后上报报警系统，更或者是发现有时钟回拨之后自动摘除本身节点并报警，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//发生了回拨，此刻时间小于上次发号时间
if (timestamp < lastTimestamp) {
 			  
           long offset = lastTimestamp - timestamp;
           if (offset <= 5) {
               try {
               	//时间偏差大小小于5ms，则等待两倍时间
                   wait(offset << 1);//wait
                   timestamp = timeGen();
                   if (timestamp < lastTimestamp) {
                      //还是小于，抛异常并上报
                       throwClockBackwardsEx(timestamp);
                     }    
               } catch (InterruptedException e) {  
                  throw  e;
               }
           } else {
               //throw
               throwClockBackwardsEx(timestamp);
           }
       }
//分配ID

四、总结

主流方案有两个：

  1. 类Snowflake方案，时钟在高位，自增在低位，保证趋势有序；保证信息安全；依赖时钟，需要考虑时钟回拨问题。
  2. 数据库号段方案，申请多个增量id，保证趋势有序；id短，不保证信息安全，适合作为DB主键；依赖DB，需要考虑DB可用性和性能问题。

附：参考链接

https://tech.meituan.com/2017/04/21/mt-leaf.html

分布式
#分布式
分布式ID
https://yzaf.top/2024/distributed/ID/
作者
why
发布于
2024年4月5日
许可协议