奇风 Java 工程师知识体系

分布式全局 Id

2023/2/17

# 为什么需要，为什么不用数据库自增ID

  • 原因1：在ERP系统中，有波次号，目前是使用波次表的自增id；如果多个公司在同一张wave表中，这个号就会很大，有需要每个公司用自己的
  • 原因2：纵向分表，Id不能连续
  • 原因3：自增ID没有实际意义，有些需要ID中包含一些可识别信息；例如身份证号

# 有哪些要求

  • 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求
  • 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能
  • 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、排序等特殊需求
  • 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；所以在一些应用场景下，会需要ID无规则、不规则
  • 可用性5个9；高QPS

# 基本解决方案

# UUID

UUID的标准型式包含32个16进制数字，以连字号分为五段，形式为xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（8-4-4-4-12）的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID

第一种方式的组成：MAC地址 + 时间戳

# 优点

  • 性能非常高：本地生成，没有网络消耗

# 缺点

  • 不易于存储：UUID太长，通常以36长度的字符串表示，很多场景不适用
  • 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露
  • ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用
    • MySQL官方有明确的建议主键要尽量越短越好
    • 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能
  • 第一种方式（MAC地址 + 时间戳）极小可能重复
    • 时钟回拨问题
    • 一个机子上部署多个应用，同时获取UUID

其他方式：

  1. DCE安全的UUID
  2. 基于名字的UUID（MD5）
  3. 随机UUID
  4. 基于名字的UUID（SHA1）

# 类snowflake方案

这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图：

image.png

41-bit的时间可以表示（1L<<41）/(1000L360024*365) = 69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID

# 优点

  • 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的
  • 可以根据自身业务特性分配bit位，非常灵活

# 缺点

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

# 数据库生成

以MySQL举例，利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增，每次业务使用下列SQL读写MySQL得到ID号：

begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;

image.png

# 优点

  • 非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护
  • ID号单调自增，可以实现一些对ID有特殊要求的业务

# 缺点

  • 强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号
  • ID发号性能瓶颈限制在单台MySQL的读写性能

对于MySQL性能问题，可用如下方案解决：在分布式系统中我们可以多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等。比如有两台机器。设置步长step为2，TicketServer1的初始值为1（1，3，5，7，9，11…）、TicketServer2的初始值为2（2，4，6，8，10…），如下所示，为了实现上述方案分别设置两台机器对应的参数，TicketServer1从1开始发号，TicketServer2从2开始发号，两台机器每次发号之后都递增2：

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

image.png

这种方案有以下缺点：

  • 系统扩展比较困难
  • ID没有了单调递增的特性，只能趋势递增，这个缺点对于一般业务需求不是很重要，可以容忍
  • 数据库压力还是很大，每次获取ID都得读写一次数据库，只能靠堆机器来提高性能

# 成熟解决方案

# 美团Leaf-segment数据库方案

segment：分段获取

原数据库方案每次获取ID都得读写一次数据库，造成数据库压力大。改为利用proxy server批量获取，每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。 各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。数据库表设计如下：

image.png

重要字段说明：biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step，大致架构如下图所示：

image.png

test_tag在第一台Leaf机器上是1~1000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是3001~4000。同时数据库对应的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号码是趋势递增
  • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务
  • 可以自定义max_id的大小，非常方便业务从原有的ID方式上迁移过来

# 缺点

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

# 双buffer优化

针对第二个缺点优化

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

为此，我们希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段

image.png

# 高可用优化

针对第三个缺点优化

采用一主两从的方式，同时分机房部署，Master和Slave之间同步数据。同时做好做主从切换。当然这种方案在一些情况下会造成数据不一致的情况，但是出现的概率非常小。如果你的系统要保证100%的数据强一致，可以选择使用“类Paxos算法”实现的强一致MySQL方案

# 美团Leaf-snowflake方案

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

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

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

image.png

# 解决时钟回拨问题

snowflake依赖时间，如果机器的时钟发生了回拨，那么就会有可能生成重复的ID号，需要解决时钟回退的问题

image.png

参见上图整个启动流程图，服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

  • 若写过，则用自身系统时间与leaf_forever/${self}节点记录时间做比较，若小于leaf_forever/${self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警
  • 若未写过，证明是新服务节点，直接创建持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize
  • 若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约
  • 否则认为本机系统时间发生大步长偏移，启动失败并报警
  • 每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}

分布式session