分布式ID生成看似简单，但在海量并发场景下要做到稳定、不重复、不阻塞，实际挑战很大。经典的雪花算法依赖系统时钟，一旦发生时钟回拨，就可能导致ID冲突；数据库号段方案虽然可靠，但每次申请新号段都需要访问数据库，在高频请求下容易成为瓶颈。美团的Leaf方案恰好解决了这些问题，提供两种核心模式——号段模式（Leaf-segment）和雪花模式（Leaf-snowflake），均基于Java实现。

Leaf-segment号段模式

核心思路非常直观：为每个业务（通过biz_tag标识）在数据库中维护一个号段（max_id），并将整个号段一次性加载到服务内存中。每次生成ID时，在内存中通过原子递增操作完成，完全避免数据库交互。当号段使用率接近阈值（例如消耗到10%）时，后台异步加载下一个号段，实现无缝衔接，杜绝阻塞。底层的数据库表结构也很典型，包含biz_tag、max_id、step、update_time等字段。Java实现中利用AtomicLong保证递增的原子性，同时结合双缓冲机制，让新旧号段的切换像舞台幕布一样自然流畅。

Leaf-snowflake模式

雪花算法本身存在单点时钟风险，Leaf的解决方案是引入ZooKeeper管理workerID：每个节点通过ZK的顺序节点获取全局唯一ID，并定期向ZK上报当前时间戳。一旦检测到时钟回拨，如果偏差小于5毫秒，服务会主动等待；如果超过5毫秒，则直接抛出异常。这相当于为雪花算法加装了一个“安全阀”，有效解决了最棘手的单点时钟问题。

实战案例：高并发订单号生成

以真实场景为例：某外卖平台日订单峰值高达1亿。他们采用Leaf-segment模式，将每个biz_tag（例如order）在数据库中的step设置为50000。服务启动时直接加载完整号段到内存，双缓冲机制确保新旧号段无缝切换。压测数据非常亮眼：单节点QPS可达10万，平均耗时仅0.5毫秒。而且由于号段申请频率低，并发冲突极小，数据库更新号段时使用乐观锁（version字段），基本不存在锁争用。

高可用部署要点

Leaf服务本身是无状态的（仅依赖ZooKeeper），可以水平部署多个实例，前端通过负载均衡分摊流量。需要注意的是，数据库主从切换时可能存在号段丢失风险——最多可能丢失一个step的号段，设计时需充分评估。此外，Leaf提供了HTTP监控接口，可实时查看每个biz_tag当前的号段使用率，方便运维人员掌握运行状态。

与UIDGenerator的对比

百度也推出了分布式ID生成器——UIDGenerator，同样基于Java实现。其特点是使用RingBuffer批量预分配ID，单机性能更高，但实现复杂度也相应提升。相比之下，Leaf更加轻量、易用，属于“拿来就能用、用起来不出错”的方案。对大多数互联网场景而言，Leaf在性能、可用性与简洁性之间取得了很好的平衡。

总结

总体来看，Leaf是工业级分布式ID生成器的一个优秀范本。它没有盲目追求极端性能，而是在性能、可用性和简单性之间找到了合适的平衡点。对于Java开发者而言，无论是参考其设计思路，还是直接集成Leaf组件，都是非常务实的选择。