解决方案


这两种分布式ID生成服务的模式，需要根据业务情况来判断，在个人学习的项目中，像一些单号的生成，或者日志的traceID我会考虑使用雪花算法ID经过我的测试，号段模式其实和雪花算法 ID 的生成吞吐量差不多的。而且号段模式，在高并发场景下，其连续递增特性，相比较趋势递增，写入性能更高，顺序写入，避免了随机 IO, 页分裂/磁盘碎片的风险。


安全考虑


但要注意的是，小哈书两种模式都有用到。针对敏感数据，如订单号，出于数据安全考虑，一般会使用雪花算法，如订单号，竞对可以根据生成的 id 来预估出平台每天的订单量；号段模式可能会有平台数据泄露的风险1.像爬虫类的很容易就猜到规律，遍历服务器资源。2.通过观察一段时间内的id，也能推测出平台大概每天平台的笔记发布量之类的。


一些知识

什么是美团Leaf？

美团 Leaf 是美团开源的分布式 ID 生成服务，旨在为分布式系统提供高效、唯一的 ID 解决方案，核心特点如下：

两种核心模式

  1. 号段模式（Leaf-Segment）

    • 预先从数据库批量获取 ID 号段（如 1000 个），缓存在内存中按需分配，减少数据库压力。

    • 适合对 ID 顺序不敏感、需高并发的场景（如订单号）。

  2. 雪花模式（Leaf-Snowflake）

    • 基于 Snowflake 算法，通过时间戳 + 机器 ID + 序列号生成 64 位唯一 ID，性能更高。

    • 依赖时钟稳定性，适合需 ID 有序递增的场景（如日志 ID）。

两种核心模式的区别，

  • 段号式有序连续，需中心化存储，获取段号有网络开销

  • 雪花算法本地生成，性能高，但ID不连续且依赖时钟

可以用Redis来做分布式ID生成服务吗？

Redis可以实现，但存在风险：

  • 持久化问题：Redis宕机可能丢失段号数据

  • 单点故障：主从切换时可能重复分配ID段

  • 容量限制：大规模系统ID生成频繁，Redis内存压力大

怎么解决雪花ID的时间回拨问题？
时钟回拨可能会导致分布式id重复
解决方法：
1.增加额外几位记录回拨次数，每次时钟回拨时位数加一，可以解决多次时钟回拨的问题；
2.借助zookeeper，可参考美团leaf的解决方法

  • 部分场景下，Leaf 可通过 ZooKeeper 获取集群内的全局一致时间，作为时间戳生成的基准。

  • 当检测到节点本地时间与 ZooKeeper 时间偏差超过阈值时，自动触发节点时间校准（需业务系统支持时间调整），从源头减少时钟回拨的可能性。