Leaf 号段模式是什么？为什么能提升分布式 ID 性能？
简化版
Leaf 号段模式是一种基于数据库批量分配 ID 的方案。ID 服务不是每生成一个 ID 都访问数据库，而是一次从数据库申请一段连续号段，比如 1000 到 1999，然后在内存中递增发号。号段用完再申请下一段。它减少了数据库访问次数，性能高，ID 趋势递增，不依赖机器时钟。常见优化是双 buffer，当前号段快用完时异步加载下一段，避免发号阻塞。
详细版
号段模式通常有一张数据库表，记录业务 tag、当前最大 ID、步长 step 等。ID 服务申请号段时，原子更新 max_id = max_id + step，并拿到旧 max_id 到新 max_id 之间的范围。之后本地内存发号即可。
优点是性能好、趋势递增、中心数据库压力低、没有 Snowflake 时钟回拨问题。缺点是依赖数据库分配号段，数据库不可用时新号段无法申请；服务重启可能浪费未用完号段；全局严格递增不保证；多业务要管理不同 tag 和步长。
双 buffer 能提升可用性：当前号段使用到一定比例时，提前异步加载下一段，保证平滑切换。
完整版教学
一、号段模式的基本思想
号段模式可以理解成“批发 ID”。如果每生成一个 ID 都访问数据库，数据库压力很大；如果一次从数据库拿一批 ID，应用在内存里慢慢发，数据库访问次数就大幅降低。比如每次申请 10000 个 ID，原来 10000 次数据库访问变成 1 次。
Leaf 号段模式就是这种思路的典型工程实现。它兼顾了数据库自增的可控性和本地发号的高性能，适合很多不想依赖机器时钟、又希望 ID 趋势递增的业务。
二、数据库表如何设计
通常会有一张号段表，字段包括业务 tag、当前最大 ID、步长 step、描述、更新时间等。不同业务用不同 tag，比如 order_id、user_id、coupon_id。申请号段时，通过数据库事务或原子 update 把 max_id 增加 step。
例如当前 max_id 是 100000，step 是 10000。某个 ID 服务申请后，数据库 max_id 更新为 110000，该服务拿到 100001 到 110000 这段 ID。之后服务本地用 AtomicLong 递增发号，不再访问数据库。
三、为什么性能更好
性能提升来自批量化。本地 AtomicLong 发号非常快，只有号段用完或预加载时才访问数据库。数据库压力从“每个 ID 一次写”变成“每个号段一次写”。步长越大，数据库访问越少。
但步长不是越大越好。步长太大，服务重启或宕机会浪费更多未使用 ID；步长太小，频繁申请号段，性能和可用性下降。实际要根据业务 QPS、可接受浪费量和数据库承载能力设置。
四、双 buffer 机制
单 buffer 的问题是当前号段用完时，必须同步访问数据库申请下一段。如果数据库短暂慢，发号请求会被阻塞。双 buffer 通过提前加载解决这个问题：当前号段使用到一定比例，比如 70%，后台异步申请下一段。
当当前号段用完时，如果下一段已经准备好，就能无缝切换。如果下一段还没加载完，才会短暂等待。双 buffer 是号段模式生产可用性的关键优化。
五、号段模式的优点
第一，不依赖系统时钟，没有 Snowflake 时钟回拨导致重复的问题。第二，ID 趋势递增，对数据库索引友好。第三，性能高，绝大多数请求本地发号。第四，业务隔离清晰，不同 tag 可以设置不同步长。
它还比较容易运维，因为核心状态在数据库表里，可查询、可审计、可调整。相比完全本地算法，号段模式更容易控制 ID 分配范围。
六、号段模式的缺点
号段模式仍然依赖数据库。当数据库长时间不可用，已有号段用完后就无法继续发号。双 buffer 只能缓解短暂故障，不能解决长期不可用。为了提高可用性，号段表所在数据库要做高可用，ID 服务也要多实例部署。
另一个缺点是会浪费 ID。服务申请了号段但没用完就重启，剩余 ID 通常不会回收，因为回收会增加复杂度和重复风险。业务必须接受 ID 不连续。事实上大多数业务只需要唯一，不应该依赖连续。
七、工程落地注意点
号段申请必须原子，不能两个服务拿到同一段。数据库 update 要带条件或使用事务，确保并发安全。ID 服务要监控号段剩余量、加载耗时、数据库异常、发号 QPS。如果预加载失败，要及时告警。
多机房场景要谨慎。如果多个机房访问同一个号段库，跨机房延迟会影响加载；如果每个机房独立号段库，就要分配不同 ID 范围或步长，避免冲突。
号段模式还要考虑动态步长。业务低峰时可以用较小 step，减少宕机浪费；业务高峰时可以自动增大 step，降低数据库更新频率。动态步长需要结合发号速度、剩余号段比例和加载耗时来调整，不能频繁抖动。监控上要重点看号段消耗速度和下一段加载是否及时。
八、常见误区与追问
这道题不能只背概念，要把「Leaf 号段模式」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Leaf 号段模式从数据库批量获取一段 ID 到内存，本地递增发号，降低数据库访问频率 | 不要停在名词解释 |
| 流程机制 | 发号服务请求号段 -> 数据库原子更新 max_id -> 返回 [old+1,new] 区间 -> 服务内存递增发号 -> 快耗尽时异步加载下一段 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | 每次取 10000 个号，服务可在内存发完这 10000 个后再取下一段，吞吐远高于每个 ID 查库 | ID 方案没有全能答案，要在唯一性、性能、可读性、索引友好和运维复杂度之间取舍 |
Leaf 号段模式 面试拆解：
1. 发号服务请求号段
2. 数据库原子更新 max_id
3. 返回 [old+1,new] 区间
4. 服务内存递增发号
5. 快耗尽时异步加载下一段记忆钩子：先说明唯一性、趋势递增、吞吐、可用性和时钟依赖，再按方案取舍；回答时要紧扣「Leaf 号段模式」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：号段模式每次生成都访问数据库。 它是批量取号，本地消耗号段。
- 误区：号段 ID 一定连续无空洞。 服务重启或号段未用完会产生空洞，但唯一性不受影响。
- 误区：数据库故障立刻不能发号。 当前内存号段没用完前仍可继续发号。
- 追问：双 buffer 有什么用？ 当前号段消耗到阈值时异步加载下一段，避免卡顿。
- 追问：号段步长怎么设置？ 按 QPS、可接受浪费和数据库压力权衡。
- 追问：优缺点是什么？ 高性能、趋势递增、依赖 DB，存在号段浪费和中心服务依赖。
九、加强记忆
Leaf 号段模式就是数据库批量发号：DB 负责分配号段，应用内存递增发号。优点是高性能、趋势递增、不依赖时钟；缺点是依赖数据库、可能浪费 ID、不保证连续。双 buffer 提前加载下一段，是避免号段切换阻塞的关键。