八股已死、场景当立(场景篇-分布式ID)
废话不多说，今天更新场景篇-分布式ID的知识点，做好了开始发车喽！
一、场景篇-分布式ID
1、Q:什么是分布式 ID？为什么在微服务/分库分表体系中必须使用它?
A:分布式 ID 是在多节点、跨机器环境下能够 全局唯一、高可用、可快速生成 的标识符。在微服务或分库分表场景中，单库自增主键会产生 单点瓶颈，且不同库之间的自增值会冲突，导致业务数据无法唯一定位。分布式 ID 通过在每个节点独立生成而不依赖中心数据库，解决了 唯一性、并发性能、水平扩展 等问题。
2、Q: 常见的分布式 ID 生成方案有哪些？请简要对比它们的优缺点？
A: 常见方案如下:
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| UUID | 基于随机数或时间戳的 128 位字符串 | 生成简单、无需依赖外部服务、全局唯一 | 长度大、无序、索引性能差、存储开销高 |
| Snowflake（Twitter） | 64 位 long：时间戳 + 机器/数据中心 ID + 序列号 | 高性能（内存生成）、有序、占用 8 字节、易扩展 | 依赖系统时钟，时钟回拨会导致冲突，需要额外处理 |
| Leaf（Segment / Snowflake） | Segment：号段预分配；Snowflake：基于 Snowflake 并通过 ZK 分配 workerId | 支持高并发、号段模式降低 DB 压力、Snowflake 模式保持有序 | 需要额外的 Zookeeper / MySQL 依赖，时钟回拨仍需防护 |
| Redis INCR | Redis 原子自增键 | 极低延迟、实现简单、可做业务前缀 | 依赖 Redis 单点或集群一致性，ID 长度受限，恢复复杂 |
| 数据库自增 + 步长 | 每库自增，步长 = 节点数 | 直接使用 DB，迁移成本低 | 单库瓶颈、扩容困难、跨库冲突风险 |
3、Q: Snowflake 算法的结构是什么？请说明每一部分的位数及含义？
A： Snowflake可以在 约 69 年 内每毫秒生成 4096（2¹²）个唯一 ID，满足多数高并发业务需求。
- 1 位符号位（固定 0）
- 41 位时间戳（相对自定义纪元的毫秒数）
- 5 位数据中心 ID（区分机房）
- 5 位机器 ID（区分同机房内的机器）
- 12 位序列号（同毫秒内的自增计数）