美团Leaf分布式ID生成器使用教程：号段模式与Snowflake模式详解
引言
在分布式系统中，生成全局唯一ID是核心需求之一。美团开源的Leaf提供了两种分布式ID生成方案：号段模式（高可用、依赖数据库）和Snowflake模式（高性能、去中心化）。本文将手把手教你如何配置和使用这两种模式，并解析其核心机制。
一、Leaf号段模式使用教程
1. 环境准备
- 数据库：MySQL 5.7+
- Java环境：JDK 1.8+
- Leaf源码：从GitHub克隆Leaf仓库（推荐使用
feature/spring-boot-starter分支）。
2. 数据库配置
2.1 创建表结构
执行以下SQL创建leaf_alloc表，用于管理号段：
CREATE TABLE `leaf_alloc` (
`biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '业务标识',
`max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '当前最大ID',
`step` int(11) NOT NULL COMMENT '号段步长',
`description` varchar(256) DEFAULT NULL COMMENT '业务描述',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
2.2 插入测试数据
初始化两个业务标识（例如订单和用户服务）：
INSERT INTO leaf_alloc(biz_tag, max_id, step, description)
VALUES ('order', 1, 2000, '订单服务'), ('user', 1, 2000, '用户服务');
3. Leaf服务配置
3.1 修改配置文件
在leaf-server/src/main/resources/leaf.properties中配置数据库连接：
leaf.name=leaf-service
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf?useUnicode=true&characterEncoding=utf8
leaf.jdbc.username=root
leaf.jdbc.password=123456
3.2 启动Leaf服务
运行LeafServerApplication，服务默认端口为8080。
4. 调用接口生成ID
通过HTTP接口获取ID：
# 获取订单服务的ID
curl http://localhost:8080/api/segment/get/order
# 获取用户服务的ID
curl http://localhost:8080/api/segment/get/user
5. 核心机制解析
- 双Buffer机制：Leaf维护两个号段缓冲区（当前和备用），当当前号段消耗10%时，异步加载下一个号段，避免数据库访问阻塞。
- 动态步长调整：根据流量变化自动调整步长（如流量翻倍时步长倍增），确保数据库压力稳定。
二、Leaf Snowflake模式使用教程
1. 环境准备
- Zookeeper：用于生成全局唯一的机器ID（
workerId）。 - Leaf源码：同上。
2. 配置Snowflake模式
2.1 修改配置文件
在leaf.properties中启用Snowflake模式并配置Zookeeper：
leaf.segment.enable=false
leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1:2181
leaf.snowflake.port=8686
2.2 启动Zookeeper
确保Zookeeper服务运行，Leaf会自动在ZK中创建持久顺序节点以分配workerId。
3. 调用接口生成ID
# 获取Snowflake模式的ID
curl http://localhost:8080/api/snowflake/get/pay
4. 核心机制解析
- ID结构：64位ID = 时间戳（41位） + 机器ID（10位） + 序列号（12位）。
- 时钟回拨处理：若时钟回拨≤5ms，等待时钟同步；若>5ms，抛出异常。
- 弱依赖ZK：首次从ZK获取
workerId后，本地缓存文件，即使ZK宕机也不影响服务。
三、两种模式对比与选型建议
| 维度 | 号段模式 | Snowflake模式 |
|---|---|---|
| 依赖 | 强依赖MySQL | 弱依赖Zookeeper |
| 性能 | 10万+ QPS（单节点） | 50万+ QPS（单节点） |
| ID趋势 | 趋势递增 | 严格单调递增 |
| 适用场景 | 高可用、允许短暂数据库不可用 | 高性能、去中心化架构 |
| 缺点 | ID规律性强，可能泄露业务量 | 依赖时钟，需解决回拨问题 |
选型建议：
- 订单系统、分库分表：优先选择号段模式，保证高可用。
- 实时日志、秒杀系统：选择Snowflake模式，追求极致性能。
四、高级功能与监控
1. 监控号段状态
访问http://localhost:8080/cache，可实时查看各业务号段的缓冲区使用情况（如剩余ID数量、加载状态）。
2. 动态调整步长
通过修改数据库中的step字段，Leaf会自动适应流量变化。例如，若QPS从1000增至2000，可将step从1000调整为2000。
五、常见问题解答
-
号段模式数据库宕机怎么办？
Leaf默认缓存两个号段，若步长设置为QPS的600倍（如QPS=1000，步长=600,000），即使数据库宕机，仍可持续服务10分钟。 -
Snowflake模式如何避免workerId冲突？
通过Zookeeper的持久顺序节点分配唯一workerId，宕机重启后仍复用原有ID。
结语
美团Leaf通过两种互补模式，为不同场景提供了灵活的分布式ID生成方案。无论是高可用的号段模式，还是高性能的Snowflake模式，均可通过本文教程快速落地。建议结合自身业务特点选择合适的模式，并关注Leaf的GitHub仓库获取最新动态。