美团Leaf是美团开源的分布式ID生成服务，核心提供号段模式（Leaf-segment）与雪花算法模式（Leaf-snowflake）两种方案，兼顾全局唯一、高可用、高性能。
一、Leaf-segment（号段模式）
1. 核心思想
基于数据库自增ID优化，批量预取号段、内存分配，大幅降低数据库访问频率。
2. 数据库设计
维护leaf_alloc表，按业务隔离发号进度：
CREATETABLE`leaf_alloc`(`biz_tag`varchar(128)NOTNULLDEFAULT'',-- 业务标识（如order、user）`max_id`bigint(20)NOTNULLDEFAULT'1',-- 当前已分配最大ID`step`int(11)NOTNULL,-- 每次取号段长度（如1000）`description`varchar(256)DEFAULTNULL,`update_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMP,PRIMARYKEY(`biz_tag`))ENGINE=InnoDB;3. 发号流程
- Leaf服务启动/号段耗尽时，执行事务：
UPDATEleaf_allocSETmax_id=max_id+stepWHEREbiz_tag=#{tag};SELECTmax_id,stepFROMleaf_allocWHEREbiz_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集群部署，配合负载均衡，单点故障不影响服务。
