全局唯一自增 ID 生成方案

用户2571261901038
597 阅读5分钟

总的来说，有三种方案：数据库自增ID、UUID生成、snowflake雪花算法。

一 数据库自增id

核心思想：使用数据库的id自增策略（如: Mysql的auto_increment）。

优点：
① 简单，天然有序。

缺点：
① 并发性不好。
② 数据库写压力大。
③ 数据库故障后不可使用。
④ 存在数量泄露风险。

解决办法： 1 数据库进行水平拆分，设置不同的初始值，并设置相同的步长。

image.png

会带来新的问题：怎么扩容？ 2 批量缓存自增id 每次生成一批不同的id让业务方去进行消费。 缺点：服务重启，单点故障会造成ID不连续。

二 Redis生成ID

Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。 优点：性能高，不依赖数据库，id天然排序，分页很好处理。 缺点：引入新组建，增加系统复杂性。

三 UUID生成方案

结合机器的网卡（基于名字空间/名字的散列值MD5/SHA1）、当地时间（基于时间戳&时钟序列）、一个随记数来生成UUID。

优点：
① 本地生成，没有网络消耗，生成简单，没有高可用风险。

缺点：
① 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
② 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
③ 无序查询效率低：由于生成的UUID是无序不可读的字符串，所以其查询效率低。

四 雪花算法

核心思想：把64-bit分别划分成多段，分开来标示机器、时间、某一并发序列等，从而使每台机器及同一机器生成的ID都是互不相同。

缺点：
①由于雪花算法是强依赖于时间的，在分布式环境下，如果发生时钟回拨，很可能会引起ID重复、ID乱序、服务会处于不可用状态等问题。

解决方案有：
a. 将ID生成交给少量服务器，并关闭时钟同步。
b. 直接报错，交给上层业务处理。
c. 如果回拨时间较短，在耗时要求内，比如5ms，那么等待回拨时长后再进行生成。
d. 如果回拨时间很长，那么无法等待，可以匀出少量位（1~2位）作为回拨位，一旦时钟回拨，将回拨位加1，可得到不一样的ID，2位回拨位允许标记3次时钟回拨，基本够使用。如果超出了，可以再选择抛出异常。

五 美团的Leaf

5.1 对数据库进行改造 对数据库进行改造，用biz_tag进行分库分表，设立最大值max_id，设置步长step，prox端一次拿step个数让业务方进行消耗，压力会减少很多。

image.png

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

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宕机会造成整个系统不可用。

针对其中号会耗完后就去请求数据库，然后tp会出现尖刺，采用双buffer解决：

在消费到某个点的时候，异步去数据库进行加载新的号段。

image.png

针对其中db宕机后整个服务不可用问题，解决如下：
数据库采用一主两从的方式，同时分机房部署。

5.2 leaf-雪花算法

数据库方案可以很好计算出一天的订单量。面对这个问题，提出了雪花算法：

image.png 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号，启动服务。

image.png

若依赖ZK:
每次从ZK上拿到workId时可在本地写个文件缓存，然后重启时如果ZK挂掉，可读取本地文件。
从而提高SLA。
解决时钟回退问题：

image.png

avatar
文章
阅读
粉丝