美团Leaf发号器

美团Leaf是美团开源的分布式ID生成服务，核心提供号段模式（Leaf-segment）与雪花算法模式（Leaf-snowflake）两种方案，兼顾全局唯一、高可用、高性能。

一、Leaf-segment（号段模式）

1. 核心思想

基于数据库自增ID优化，批量预取号段、内存分配，大幅降低数据库访问频率。

2. 数据库设计

维护 leaf_alloc 表，按业务隔离发号进度：

sql 复制代码

CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128) NOT NULL DEFAULT '', -- 业务标识（如order、user）
  `max_id` bigint(20) NOT NULL DEFAULT '1',    -- 当前已分配最大ID
  `step` int(11) NOT NULL,                     -- 每次取号段长度（如1000）
  `description` varchar(256) DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

3. 发号流程

Leaf服务启动/号段耗尽时，执行事务：

sql 复制代码

UPDATE leaf_alloc SET max_id = max_id + step WHERE biz_tag = #{tag};
SELECT max_id, step FROM leaf_alloc WHERE biz_tag = #{tag};

拿到新号段 [max_id-step+1, max_id]，缓存到本地内存。
业务请求ID时，直接从内存递增分配，无DB交互、性能极高。

4. 关键优化：双缓存（Double Buffer）

维护两个号段缓存：当前可用段、备用段。
当前段消耗至**10%**时，异步预取下一个号段到备用段。
当前段耗尽，立即切换到备用段，消除取号段时的请求阻塞。

5. 特点

优点：全局严格递增、DB压力低、可水平扩展、支持多业务隔离。
缺点：ID非绝对连续（号段切换可能跳号）、依赖DB可用性。

二、Leaf-snowflake（雪花算法模式）

1. 核心思想

基于Twitter Snowflake改进，用时间戳+机器ID+序列号 生成64位ID，保证趋势递增、全局唯一。

2. 64位ID结构（1+41+10+12）

1位：符号位，固定为0（保证ID为正数）。
41位：时间戳（毫秒级，可使用约69年）。
10位：机器ID（WorkerID，支持1024台节点）。
12位：序列号（同一毫秒内自增，支持4096个ID/ms）。

3. 关键优化

WorkerID自动分配
- 依赖ZooKeeper持久顺序节点，服务启动时自动注册并获取唯一WorkerID，无需手动配置。
- 流程：连接ZK → 检查leaf_forever节点 → 存在则取回ID，不存在则创建顺序节点并获取序号。
时钟回拨解决
- 启动时校验本地时间与ZK记录时间，时间回拨则启动失败并告警。
- 运行中定时上报时间到ZK，发现回拨则暂停发号、等待时间追赶。

4. 特点

优点：纯内存生成、性能极高（QPS可达数十万）、趋势递增、不依赖DB。
缺点：依赖时间同步、强依赖ZK、ID非严格连续。

三、两种模式对比

特性	Leaf-segment（号段模式）	Leaf-snowflake（雪花模式）
ID连续性	全局严格递增	趋势递增（同一毫秒内连续）
性能	高（内存分配，DB低访问）	极高（纯内存，无IO）
依赖组件	MySQL	ZooKeeper + 时间同步
水平扩展	易（多节点取不同号段）	易（WorkerID唯一即可）
适用场景	订单号、流水号、需严格递增场景	用户ID、消息ID、高并发通用场景

四、整体架构

Leaf Server：独立部署的发号服务，提供RPC/HTTP接口供业务调用。
业务方：无需本地生成，直接调用Leaf Server获取ID，解耦业务与发号逻辑。
高可用：Leaf Server集群部署，配合负载均衡，单点故障不影响服务。