分布式 ID 生成

• 号段预取与批量消耗
• 双 buffer 的预加载与切换
• 断点续取与高并发

Leaf 的号段（Segment）模式是一种"批量取号"的分布式 ID 方案：为减少数据库访问频率，Leaf 每次从数据库取一段连续的 ID（如某个区间），在内存中逐号消耗，用完后再取下一段。数据库只需维护"当前段起始值 + 步长"，通过一条 UPDATE 更新段起始值即可，避免逐条写库。双 buffer 机制是：Leaf 维护两个号段 buffer（当前段与预备段），当当前段消耗到阈值（如 10%）时，后台线程立即去数据库加载下一段到预备 buffer，耗尽当前段后无缝切换，从而避免"取号时等待数据库"造成的阻塞，保证高并发下 ID 分配不间断。该方案把"数据库 IO"与"号码消耗"解耦，兼顾了吞吐与成本，是美团 Leaf 号段模式的核心。

号段模式的关键是"用一批号换一次数据库访问"，双 buffer 再进一步用"提前预取 + 后台加载"消除切换时的等待。它解决了"每次取号都访问 DB"的瓶颈，也避免了"ID 用尽时服务停顿"。

• 分片键与 ID 的关联
• 取模路由与一致性
• 全局唯一与局部有序

在分库分表场景下，分布式 ID 常与分片（分库分表）键协同工作：分片路由通常用某个字段（如用户 ID、订单号）对表数量取模，决定数据落在哪张表。为保证路由正确，分布式 ID 的生成必须与分片策略一致：要么直接用分片键作为 ID 的组成部分（如"表号 + 自增"），要么保证 ID 中蕴含的取模信息与分片键一致，否则同一业务数据会被分散到不同表导致查询失效。常见做法包括：用"分片号拼接自增序号"作为 ID，使 ID 段按表分布；或提前用分片键计算表号，再生成 ID。另一方面，分布式 ID 的全局唯一性由多节点不冲突保证，而有序性（如趋势递增）有助于主键索引的顺序写入，减少页分裂。因此设计时需同时考虑"唯一性、可选的有序性、以及与分片键的路由一致性"。

分布式 ID 与分片键协作的核心是"ID 必须与分片路由兼容"。若 ID 生成与取模路由脱节，会产生"数据分布不均"或"查询跨表"的问题。设计上应让 ID 蕴含分片信息或与分片键绑定。

• TraceId/SpanId 的生成
• 全链路关联日志
• 分布式 ID 的全局唯一与生成时机

在分布式系统中，一个请求会跨多个服务、多个日志文件，分布式 ID 被用作链路追踪的 TraceId（链路 ID）与 SpanId（一次调用 ID），从而把散落在各服务的日志关联成一条完整链路。TraceId 在请求入口生成并在 RPC 调用中透传，SpanId 记录每次调用的父子关系，配合服务名、时间戳、调用耗时等，就能还原"请求从网关到各下游"的完整调用链，用于排障、性能分析与依赖梳理。分布式 ID 的全局唯一性是链路追踪正确关联的前提，同时要求生成开销小、支持高并发（每请求生成 TraceId 与可能多个 SpanId），通常用 Snowflake 或轻量随机串实现。日志中还常用该 ID 作为检索键，实现按请求聚合日志。

分布式 ID 在链路追踪中的核心价值是"作为跨服务关联的锚点"。TraceId 保证"整条链路可聚合"，SpanId 保证"一次调用可定位"，二者共同构成分布式链路追踪的基础。

• ZK 临时顺序节点分配 workerId
• 时钟回拨与弱化依赖
• 缓存与本地回退

Leaf-Snowflake 用 ZooKeeper 为每个机器分配 workerId：机器启动时在 ZK 指定的持久节点下创建临时顺序节点，取返回的序号作为全局唯一 workerId，从而保证不同机器 workerId 不冲突。其强依赖表现为：若 ZK 不可用，新机器无法获得 workerId 而无法启动，形成对 ZK 的强依赖。为弱化依赖，Leaf 做了优化：启动时若 ZK 可用则正常分配并缓存 workerId 到本地磁盘；若 ZK 不可用，则读取本地缓存的 workerId 进行恢复，避免每次启动都必须依赖 ZK；同时配合时钟回拨检测（若发现时间回拨超过阈值则暂停服务或报错），在 ZK 故障时仍能尽量提供可用性。这样把"强依赖在线 ZK"降级为"启动时优先使用 + 本地缓存兜底"。

ZK 强依赖的根源是"workerId 必须全局唯一"这一需求，而从 ZK 一次分配后 workerId 不会变化，因此可以缓存到本地、弱化对 ZK 的在线依赖。核心是"一次分配、长期复用、本地恢复"。

• ZK 临时顺序节点分配
• 数据库号段分配
• 两种方式的取舍

Leaf-Snowflake 的 workerId 分配主要有三种方式：一是通过 ZooKeeper 分配，机器启动时在 ZK 的持久节点下创建临时顺序节点，取返回序号作为 workerId，优点是全局唯一、自动分配、可感知机器下线；二是通过数据库分配，用数据库表维护 workerId 的分配记录（如自增或号段），适合没有 ZK 的场景；三是通过配置/本地文件在部署时指定 workerId，适合机器数量少且可手工管理的场景。ZK 方式最常用（也是 Leaf 默认方案），因为它能自动协调多机器、避免人工配置冲突；数据库方式用数据库的原子性保证唯一，但引入 DB 依赖。选择时需权衡"是否需要 ZK 基础设施"与"workerId 管理的自动程度"。无论哪种方式，最终都要求 workerId 在集群内唯一且 ≤1023（10 位）。

workerId 分配的核心是"保证全局唯一且不越界（10 位上限）"。ZK 临时节点提供了自动、可感知下线的方式，数据库提供无 ZK 场景的替代。实际中"自动分配 + 本地缓存"是平衡可用性与一致的常见组合。

• Segment 模式的有序与依赖 DB
• Snowflake 模式的趋势递增与依赖时间
• 两者的选型

美团 Leaf 提供两种分布式 ID 方案。Segment（号段）模式：从数据库批量取号段，ID 严格递增、有序，适合对"有序性"有要求（如主键顺序写入、磁盘顺序 IO）的场景，但依赖数据库，且若 DB 故障会导致取号失败；它通过双 buffer 提升吞吐。Snowflake（雪花）模式：基于"时间戳 + 机器号 + 序列号"生成趋势递增 ID，不依赖数据库、吞吐高、可扩展，适合"高并发、需要趋势递增、不希望强依赖存储"的场景，但依赖机器时钟（需处理时钟回拨）且 ID 非严格连续。选型上：对 ID 有序性要求高、能接受 DB 依赖选 Segment；对高并发、低依赖、可接受趋势递增选 Snowflake。两者也可结合，按业务对 ID 的形态要求选择。

Segment 与 Snowflake 的核心差异是"有序的来源"：Segment 靠数据库批量分配保证严格有序，Snowflake 靠时间戳保证趋势有序。选型取决于"是否需要严格有序"与"能否接受存储/时钟依赖"。

• 时钟回拨导致 ID 重复
• 回拨的检测与处理
• 等待、拒绝、备用时间等方案

Snowflake 依赖系统时间戳生成 ID，若系统时钟发生回拨（如 NTP 校时、管理员调整），可能会生成与之前重复的 ID，破坏唯一性。常见解决方案有：最小时延等待——若回拨幅度很小（如几十毫秒），进程等待时钟追上后再继续生成，适用于小回拨；抛异常拒绝——若回拨超过阈值（如 5ms），直接抛异常停止生成，避免产生重复 ID，但会中断服务；记忆上次 ID 并递增——记录上次生成的时间戳，若当前时间回拨到最后一次时间戳之前，则用"上次时间戳 + 1"逻辑补偿，保证不回退；备用时钟方案——双时钟或从 NTP 服务器比对，判断时钟是否可信。工程上常组合使用：小时延等待、大回拨抛异常或使用 LastTimestamp 回退补偿，并配合告警。核心是"宁可拒绝生成，也不产生重复 ID"。

时钟回拨的本质是"时间戳倒退导致取号序列重叠"。解决思路要么"等时钟回来"（等待）、要么"拒绝生成"（抛异常）、要么"保证序列不回退"（用上次时间戳补偿）。业务可用性与 ID 唯一性之间需权衡。

• 41 位可表示的时间范围
• 以毫秒为单位的换算
• 起始时间与 overflow 处理

Snowflake 的 ID 中 41 位用于表示时间戳（相对某个起始时间的毫秒数）。2^41 ≈ 2.2×10^12 毫秒 ≈ 2.2×10^9 秒 ≈ 69.7 年。因此从起始时间（如 2010 年）起，该算法理论上可用约 69 年，超过后时间戳位溢出，无法再生成新的唯一 ID。工程上通常需要约定一个起始时间（epoch），并在 69 年后通过更换 epoch、扩展 bit 布局或迁移到新方案解决。需要注意的是：41 位是"距 epoch 的毫秒偏移"，不是"绝对时间"，所以不同的 epoch 会改变可用年限起点。设计时需评估业务生命周期，预留足够余量。

69 年 = 2^41 毫秒 换算而来。这是 Snowflake 的"使用年限"约束，源于时间戳只占 41 位。理解它有助于在方案设计时评估长期可用性，必要时调整位布局。

• sequence 位数的容量
• 每毫秒可生成的 ID 数
• 溢出与等待策略

Snowflake 的 sequence 位（通常 12 位）表示同一毫秒内的序列号，可表示 0~4095 共 4096 个值。因此单机单毫秒最多生成 4096 个 ID，即单机 QPS 上限约为 4096×1000 = 409 万/秒。若同一毫秒内请求数超过 4096，ID 会溢出：常见策略是"自旋等待到下一毫秒"（即阻塞直至时间戳变化再继续），从而保证不重复；也可以通过扩展序列位宽来提高单机吞吐，但会挤占其他位。实际中单机通常远达不到 409 万 QPS，但理解该上限有助于评估容量与是否需要分片。sequence 位还用于区分同一毫秒内的不同 ID，配合时间戳与机器号保证全局唯一。

sequence 位决定"单毫秒并发容量"，12 位=4096 个/毫秒，乘 1000 得约 409 万 QPS。溢出时"等待下一毫秒"是标准做法，牺牲一瞬间的延迟换取唯一性。

• 各字段的位数与含义
• 容量与可用年限
• 位布局的可定制性

标准 Snowflake ID 为 64 位 long，分布为：1 位符号位（固定为 0，保证正数）；41 位时间戳（相对于 epoch 的毫秒数，约 69 年可用）；10 位机器号（workId，可标识 1024 台机器，5 位 datacenterId + 5 位 workerId 或 10 位 workerId）；12 位序列号（同一毫秒内可生成 4096 个 ID）。这样组合后，单机单毫秒可生成 4096 个 ID，支持 1024 台机器，理论上覆盖大规模集群。位布局可定制：例如减少机器号位数、增加序列号位以提升单机吞吐，或调整时间戳起始以延长可用年限。各字段从高到低排列，保证 ID 数值上大致按时间递增（趋势递增），利于数据库主键顺序写入。

位分配是 Snowflake 的"配置灵魂"：时间戳保证有序、机器号保证跨机唯一、序列号保证同机同毫秒唯一。1+41+10+12 是经典分配，可根据场景调整各字段位数。

• 静态配置
• 动态分配（ZK/DB/中心化）
• 分配上的唯一性保证

Snowflake 的机器 ID（workerId）分配策略主要有：静态配置法——在部署时通过配置文件或环境变量为每台机器手工指定 workerId，简单但需人工保证不冲突，适合机器数量少、变化不频繁的场景；动态分配法——启动时从 ZooKeeper、数据库或专门的分配服务获取一个全局唯一的 workerId（如 ZK 临时顺序节点、数据库自增/号段），自动协调避免冲突，适合大规模动态集群；混合法——优先从中心化服务获取，失败时用本地缓存或按范围约定回退。无论哪种方式，核心都是保证 workerId 在集群内全局唯一且不超过位数上限（如 10 位 ≤1023）。动态分配更利于自动化运维，静态配置更简单但易出错。

workerId 分配的核心矛盾是"唯一性与自动化"：静态配置简单但不自动，动态分配自动但依赖外部服务。实际工程常以"动态分配 + 本地缓存"兼顾两者。

• 64 位 ID 的构成
• 时间戳、机器号、序列号协作
• 趋势递增与唯一性

Snowflake（雪花）算法生成 64 位 long 型分布式 ID，由"时间戳 + 机器号 + 序列号"三部分组成：高 41 位是相对起始时间的毫秒时间戳，中间 10 位是机器号（workerId），低 12 位是同一毫秒内的序列号。生成流程：取当前时间戳，若与上次记录的时间相同则序列号 +1；若序列号达到上限则转入下一毫秒（等待）；若时间戳大于上次记录则序列号重置为 0。这样组合出的 ID 全局唯一（不同机器靠机器号区分、同机靠时间戳+序列号区分），且数值上随时间大致递增（趋势递增），适合作为数据库主键顺序写入。它不依赖数据库、单机可独立生成、吞吐高，是业界最流行的分布式 ID 方案之一。

Snowflake 的巧妙之处是"用机器号分片、用时间排序、用序列号去重"，三者叠加在 64 位内实现"全局唯一 + 趋势有序 + 无中心依赖"。理解其关键字段与生成流程，就能自定义调整。

• 号段批量获取
• 预加载下一段
• 异步分发与高并发

TinyID（滴滴）是号段模式的分布式 ID 服务，其核心是"号段 + 预加载 + 异步分发"。服务端从数据库批量获取一个号段（如 1000 个 ID），在内存中逐号分配；当内存中的号段消耗到阈值（如剩余 20%）时，后台线程异步向数据库预加载下一段，避免用户取号时停顿。通过"预加载"，客户端取号请求几乎不等待数据库，极大提升吞吐。TinyID 还支持多段并行预加载和缓存，进一步降低取号延迟。相比每次取号都访问数据库，这种"批量取号 + 后台预取"的模式把数据库压力降到最低，并保证 ID 的连续性（趋势递增）。其异步分发通过在后台线程池中完成预取，使取号主路径只有内存操作。

TinyID 与 Leaf 号段类似，核心是"用批量取号换数据库访问次数、用预加载消除取号等待"。异步分发让预取与消耗解耦，是高并发 ID 服务的常见优化。

• 号段表与批量取号
• 服务端与客户端架构
• 失败重试与可用性

TinyID（滴滴）的号段模式通过"数据库 + 内存号段"实现高效分布式 ID：数据库中维护一张号段表，记录每个业务（bizType）的当前 ID 起点与步长；服务端取号时，先用一条 UPDATE 把该业务的起点增加步长，从而"取走"一段号段，再在内存中逐号分配。当内存号段消耗到阈值时，再次向数据库预取下一段。TinyID 提供服务端（TinyIdServer）与客户端（TinyIdClient）两层：服务端负责管理号段与分配，客户端通过网络请求批量获取号段并本地缓存、本地分配，降低对服务端的调用频率。客户端取号失败时可通过重试或回退到其他服务端节点保证可用性。该方案兼顾了高并发（单次取号拿一段）与 ID 连续性（同段内递增）。

TinyID 号段模式的核心是"数据库滚动号段 + 客户端缓存分配"。它把"取号"从每次请求变成"批量预取"，并让客户端分摊部分分配逻辑，从而支撑高并发业务。

• v1 基于时间与 MAC
• v4 随机生成
• v7 时间有序随机

UUID 有多个版本，工程上主要关注 v1、v4、v7。UUID v1：基于时间戳 + 节点地址（MAC）+ 时钟序列生成，可包含时间信息，但会暴露 MAC 地址（有隐私风险），且无序性差（不适合作为数据库主键随机插入）。UUID v4：完全随机生成，唯一性概率极高、无需任何状态，但完全无序，作为主键会导致 B+ 树随机插入、页分裂频繁，性能差。UUID v7：基于"时间戳 + 随机数"生成，既有时间信息（可排序、趋势递增），又保留随机性，适合作为数据库主键，兼顾有序性与唯一性，是近年来推荐的新版本。工程取舍：v1 适合需要时间信息的场景但不推荐暴露 MAC；v4 适合无排序需求的场景；v7 作为主键表现最佳，是现代应用首选。

v1 有序但暴露 MAC、v4 随机但无序、v7 时间有序又随机。选型核心是"是否作为主键"与"是否接受时间排序"——作为主键时 v7 最合适。

• uuid-creator 库的 API
• UUID v7 的时间戳 + 随机结构
• 对比 v4 随机 UUID

com.github.f4b6a3:uuid-creator 是一个高可用、线程安全的 Java UUID 生成库，API 简洁，支持多种 UUID 版本（v1、v4、v6、v7 等），并针对性能做了优化。工程中它常被用来生成 UUID v7：v7 的 128 位结构中，前 48 位为毫秒时间戳，后 80 位为随机数（含版本/变体位），因此 v7 既是"时间有序"的（可按时间排序），又保留随机性，适合作为数据库主键，避免 v4 的随机插入导致的索引碎片。使用示例：UuidCreator.getTimeOrdered() 快速生成 v7。相比 v4，v7 在有时间排序需求时更优；相比 v1，v7 不暴露 MAC 地址，隐私更好。该库通过简单的静态方法即可生成，适合在 Java 应用中直接使用。

uuid-creator 提供了"一条语句生成 v7"的便捷 API。v7 的价值在于"时间有序 + 随机防冲突"，既满足主键排序需求又避免暴露机器信息，是现代 Java 应用的首选。

• 时间单位与秒/毫秒
• 位布局与容量
• 各自适用场景

sonyflake 是 Sony 开源的分布式 ID 生成器，与 Snowflake 类似但位布局不同。核心差异：时间戳单位不同——Snowflake 用毫秒、sonyflake 用 10 毫秒（msec）为单位（1 位保留位 + 时间戳 39 位基于 10 毫秒单位，可表示约 174 年）；可用时长不同——sonyflake 约可用 174 年，长于 Snowflake 的约 69 年；序列号与机器号容量不同——sonyflake 用 8 位序列号（每个时间单位 256 个）+ 16 位机器号（最多 65536 台机器），而 Snowflake 用 12 位序列号（每毫秒 4096）+ 10 位机器号（1024 台）。sonyflake 适合"机器数较多、时间粒度稍粗"的场景，且 10 毫秒单位使可用年限更长；Snowflake 时间粒度更细（毫秒）、单机容量更大，适合要求毫秒级细分、机器数适中的场景。两者都需处理时间戳回拨与各自字段的溢出。

差异集中在"时间单位（10 毫秒 vs 1 毫秒）、机器号位数（16 vs 10）、序列号位数（8 vs 12）"。sonyflake 用 10 毫秒单位换取更长的可用年限（约 174 年）与更大的机器容量；Snowflake 用 1 毫秒提供更细粒度与更大的单机容量。