分布式 ID 需要满足哪些要求？为什么不能直接用普通自增 ID？
简化版
分布式 ID 的核心要求是全局唯一、高性能、高可用、趋势递增、长度合适、可排序、最好能携带一定业务或时间信息。普通数据库自增 ID 在单库单表里好用，但分库分表、多服务并发写入、多机房部署后会遇到单点瓶颈、扩展困难、ID 冲突、跨库排序不方便等问题，所以需要专门的分布式 ID 方案。
详细版
分布式 ID 首先必须全局唯一，这是底线；其次要生成速度快，因为订单、消息、日志、业务流水都可能高并发生成；还要高可用，不能因为 ID 服务挂了导致核心业务无法写入。
很多场景还希望 ID 趋势递增。趋势递增对数据库索引友好，尤其是 MySQL InnoDB 聚簇索引，随机 ID 会导致页分裂和写入抖动。ID 还要长度可控，太长会增加存储和索引成本；最好能按时间粗略排序，方便排查和归档。
常见方案包括 UUID、数据库自增、数据库号段、Redis INCR、Snowflake、Leaf 等。没有绝对最优方案，要根据唯一性、性能、可用性、排序性、运维复杂度和时钟依赖来选。
完整版教学
一、分布式 ID 解决的根本问题
在单机系统里，ID 生成很简单。一个数据库表自增主键就能保证唯一。但系统拆成微服务、数据库拆成分库分表、应用部署多实例以后，多个节点会同时创建订单、用户、消息、支付流水。如果每个节点各自生成 ID，就可能冲突；如果都去一个数据库拿 ID，又会形成瓶颈和单点。
分布式 ID 的目标是在多节点并发环境下，以足够低的成本生成业务可接受的唯一标识。它看起来只是一个数字或字符串，但会影响写入性能、索引结构、排查效率、扩容方式和系统可用性。
二、全局唯一是底线
ID 最重要的要求是全局唯一。订单号重复、支付流水重复、消息 ID 重复，都会直接造成业务混乱。唯一性不仅要在单服务内成立，还要在多实例、多机房、多库表、历史迁移和故障恢复后成立。
唯一性还要考虑边界场景。比如机器重启后 workerId 是否重复，Redis 主从切换是否丢增量，数据库号段是否重复发放，Snowflake 时钟回拨是否生成旧时间戳 ID。面试里只说“保证唯一”不够，最好能说出唯一性会被哪些工程问题破坏。
三、性能和可用性为什么重要
很多业务写入都依赖 ID。如果 ID 服务不可用，订单创建、消息发送、日志写入都可能停摆。因此 ID 生成不能成为核心链路的薄弱点。性能上，ID 生成通常要能支撑高 QPS，并且延迟稳定。
本地生成方案如 Snowflake 性能很高，但依赖机器号和时钟；中心化方案如数据库、Redis 更容易理解，但可能有单点和网络开销；号段方案通过一次取一批 ID 降低中心压力，是性能和可控性之间的折中。
四、趋势递增对数据库很关键
如果 ID 用作 MySQL InnoDB 主键，是否递增会明显影响写入性能。InnoDB 的聚簇索引按主键组织数据，递增 ID 基本追加写入，页分裂少；完全随机 ID 会插入到索引树的随机位置，导致页分裂、缓存命中下降、磁盘写放大。
所以很多业务不喜欢直接用 UUID 做主键。UUID 虽然生成简单、全球唯一概率高，但随机性强、长度大、索引不友好。趋势递增 ID 在数据库写入、分页排序、按时间归档上更有优势。
五、ID 是否要可读和携带信息
有些 ID 只给系统内部使用，只要唯一即可；有些 ID 会暴露给用户或客服，比如订单号、工单号、交易流水号。这类 ID 可能需要长度适中、可复制、可读性好，甚至包含日期、业务类型、渠道等信息。
但携带信息也有风险。ID 中暴露时间、业务线、机器号，可能泄露业务量或架构信息；过度编码会降低灵活性。工程上常见做法是内部主键和外部单号分离：内部用高性能数字 ID，外部用带规则的业务单号。
六、常见方案怎么初步选择
如果只是低并发、单库单表，数据库自增最简单。如果高并发但能接受中心化依赖，Redis INCR 可以快速实现。如果需要高性能本地生成，并且能管理机器号和时钟，Snowflake 很常见。如果希望减少数据库压力又不依赖本机时钟，号段模式很适合。
面试里不要背“Snowflake 最好”。更稳的回答是：先看是否需要趋势递增，是否作为数据库主键，QPS 多高，是否允许中心依赖，能否接受时钟风险，是否多机房。需求不同，答案不同。
七、落地检查清单
设计分布式 ID 时可以按清单检查：是否全局唯一，是否高并发，是否高可用，是否趋势递增，长度是否可接受，是否能粗略按时间排序，是否能支持分库分表，是否需要隐藏业务量，是否方便排查，是否有故障兜底。
还要做容量评估。比如 Snowflake 每毫秒序列位能生成多少 ID，业务峰值会不会超过；号段模式每次取多少号段，DB 挂了本地缓存能撑多久；Redis ID 主从切换是否可能回退。ID 方案上线前必须压测和故障演练，因为 ID 一旦重复，修复成本很高。
八、常见误区与追问
这道题不能只背概念，要把「分布式 ID 要求」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 分布式 ID 通常要求全局唯一、高性能、高可用、趋势递增、长度可控和可解析信息可选 | 不要停在名词解释 |
| 流程机制 | 多个节点同时请求 ID -> 生成器保证唯一分段或位组合 -> 返回趋势递增值 -> 业务写入数据库 -> 监控时钟和号段消耗 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | 订单表每秒写入 5 万行时，随机 UUID 会让 B+ 树频繁分裂，趋势递增 ID 更利于索引 | ID 方案没有全能答案，要在唯一性、性能、可读性、索引友好和运维复杂度之间取舍 |
分布式 ID 要求 面试拆解：
1. 多个节点同时请求 ID
2. 生成器保证唯一分段或位组合
3. 返回趋势递增值
4. 业务写入数据库
5. 监控时钟和号段消耗记忆钩子：先说明唯一性、趋势递增、吞吐、可用性和时钟依赖，再按方案取舍；回答时要紧扣「分布式 ID 要求」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：只要唯一就够了。 还要考虑索引友好、吞吐、可用性、长度和安全暴露。
- 误区：递增 ID 永远最好。 连续递增可能暴露业务量，且中心化生成有瓶颈。
- 误区：ID 生成可以依赖单点数据库。 高可用场景要考虑生成器故障和扩容。
- 追问：为什么趋势递增重要？ 减少数据库 B+ 树页分裂，提升插入性能。
- 追问：ID 是否要包含业务含义？ 核心 ID 尽量少耦合业务，可通过单独字段表达业务属性。
- 追问：常见方案有哪些？ UUID、数据库自增、Redis INCR、号段模式、Snowflake。
九、加强记忆
分布式 ID 的底线是全局唯一，常见附加要求是高性能、高可用、趋势递增、长度可控、可排序、易排查。普通自增 ID 在单库好用，但分布式场景会有单点、瓶颈和冲突风险。选型要看业务需求，不是固定答案：低并发用自增，高性能本地生成用 Snowflake，减少中心压力可用号段，简单计数可用 Redis。