13. Distributed ID Generator 分布式ID生成器

V1 — 1个用户：前端生成唯一ID

场景

你在做一个纯前端笔记应用，每条笔记需要一个唯一ID。没有后端，需要在浏览器里生成不重复的ID。

你要解决什么

用纯JavaScript生成本地唯一ID，保证单用户场景下不重复。

给AI的Prompt

帮我用纯HTML+JavaScript实现一个前端ID生成器：

1. 实现三种ID生成方式并对比：
   - 方式A：Date.now() + Math.random().toString(36).substr(2, 9)
   - 方式B：crypto.randomUUID()（浏览器原生）
   - 方式C：自增计数器（存localStorage，从1开始）
2. 一个笔记应用演示：
   - 创建笔记时自动分配ID
   - 笔记列表显示ID、标题、创建时间
   - 存localStorage
3. ID测试面板：
   - 批量生成10000个ID，检测是否有重复
   - 显示每种方式的生成速度（ops/sec）
   - 显示ID长度和格式示例
4. 可视化对比表格：方式、长度、可排序性、碰撞概率、浏览器兼容性

不用任何框架，纯原生JS。

验证清单

• 三种方式都能生成ID
• 10000个ID无重复
• 笔记CRUD正常工作
• 对比表格信息准确

你学到了什么

• UUID的格式和碰撞概率 → Module: 唯一标识设计
• 前端ID方案的局限性（多标签页、多设备） → Module: 分布式基础

---

V2 — 10个用户：数据库自增ID

场景

笔记应用加了后端，10个用户注册使用。需要后端统一分配ID，保证全局唯一。

你要解决什么

用Go后端结合数据库自增ID和UUID，实现可靠的ID生成。

给AI的Prompt

帮我用Go+Gin+SQLite实现后端ID生成：

1. 两种ID策略并存：
   - 数据库自增ID：用于内部关联（用户看不到）
   - UUID v4：用于外部暴露（API返回给前端）
2. 数据模型：
   - notes表：id(自增), uuid(唯一索引), title, content, user_id, created_at
   - 创建笔记时自动生成UUID
3. API设计：
   - POST /api/notes — 创建笔记，返回uuid
   - GET /api/notes/:uuid — 通过uuid查询
   - 内部查询用自增id（外键关联），外部一律用uuid
4. 为什么不直接暴露自增ID（安全考虑）：
   - 写一个文档注释说明：自增ID可被遍历、暴露数据量
5. 简单性能测试：
   - 批量插入1000条记录，统计耗时
   - 验证UUID唯一性约束

注意：SQLite单文件即可，不需要额外数据库服务。

验证清单

• 创建笔记返回UUID而非自增ID
• 通过UUID能正确查询到笔记
• 自增ID不出现在任何API响应中
• 1000条批量插入无UUID冲突

你学到了什么

• 内部ID vs 外部ID的设计哲学 → Module: API安全设计
• 自增ID的安全隐患（IDOR攻击） → Module: Web安全
• SQLite作为轻量存储的适用场景 → Module: 数据库选型

---

V3 — 100个用户：Snowflake算法

场景

系统需要生成有序且唯一的ID，用于消息排序、事件追踪。UUID太长且无序，自增ID在分布式下有瓶颈。

你要解决什么

实现Snowflake算法，生成64位有序唯一ID，兼顾唯一性和可排序性。

给AI的Prompt

帮我用Go实现Snowflake ID生成器：

1. 64位ID结构：
   - 1位符号位(固定0)
   - 41位时间戳(毫秒，支持约69年)
   - 10位机器ID(支持1024台机器)
   - 12位序列号(每毫秒4096个ID)
2. 核心实现：
   - 时钟回拨处理：检测到回拨时等待或报错
   - 同一毫秒内序列号自增，溢出则等待下一毫秒
   - 提供ID解析：从ID反解出时间、机器ID、序列号
3. HTTP服务：
   - POST /api/id/generate — 生成单个ID
   - POST /api/id/batch?count=100 — 批量生成
   - GET /api/id/parse/:id — 解析ID各字段
4. 性能测试：
   - 单goroutine每秒生成数
   - 100个goroutine并发生成100万个ID，验证无重复
5. 与UUID对比：
   - 长度：Snowflake 8字节 vs UUID 16字节
   - 可排序：Snowflake按时间有序 vs UUID无序
   - 数据库索引友好度对比

提供完整的生成器结构体和并发安全实现。

验证清单

• 生成的ID按时间递增
• 100万并发ID无重复
• ID解析能还原时间戳和机器ID
• 时钟回拨时正确处理

你学到了什么

• Snowflake算法的位运算设计 → Module: 分布式ID算法
• 时钟回拨问题及应对 → Module: 分布式时钟
• 有序ID对数据库B+Tree索引的友好性 → Module: 数据库索引

---

V4 — 1000个用户：号段模式

场景

Snowflake依赖机器时钟，时钟漂移时有风险。同时每次生成ID都要调用生成器，需要更高性能的方案。

你要解决什么

实现号段模式，从数据库批量取一段ID缓存到本地，大幅减少DB访问。

给AI的Prompt

帮我用Go+PostgreSQL实现号段模式ID生成器：

1. 数据库号段表：
   - id_segments: biz_tag(业务标识), max_id(当前最大ID), step(步长), version(乐观锁)
   - 初始配置：order业务step=1000, user业务step=500
2. 号段加载逻辑：
   - 每次从DB取一个号段[max_id+1, max_id+step]
   - 用乐观锁(version)防止并发取号段冲突
   - 取回后缓存在内存，用完再取下一段
3. 双Buffer优化：
   - 维护两个号段(current和next)
   - 当current消耗到10%时，异步加载next
   - current用完无缝切换到next，零等待
4. 不同业务不同号段：
   - 订单ID：前缀ORD + 号段ID
   - 用户ID：前缀USR + 号段ID
5. API接口：
   - POST /api/id/:biz_tag — 按业务获取下一个ID
   - GET /api/id/:biz_tag/status — 查看当前号段消耗进度
6. 监控：号段剩余量低于20%时日志告警

重点关注双Buffer的异步加载和无缝切换逻辑。

验证清单

• 不同业务获取独立的ID序列
• 号段用完自动从DB加载下一段
• 双Buffer切换时ID不中断不重复
• 乐观锁冲突时能重试成功

你学到了什么

• 号段模式 vs Snowflake的取舍 → Module: ID方案对比
• 双Buffer预加载思想 → Module: 缓存预热
• 乐观锁在高并发下的应用 → Module: 并发控制

---

V5 — 1万用户：多机部署

场景

系统扩展到多台服务器，每台都运行号段服务。需要确保不同机器不会分配到重叠的号段。

你要解决什么

多机器部署ID生成服务，通过worker ID分配和号段隔离避免ID冲突。

给AI的Prompt

在V4基础上实现多机部署方案：

1. Worker ID分配：
   - 基于数据库注册：启动时向workers表注册，获取唯一worker_id
   - 心跳续约：每30秒更新heartbeat，超时180秒视为下线
   - 下线worker的ID可被新实例复用
2. 号段隔离策略：
   - 方案A：每台机器取不同号段（DB层面隔离）
   - 方案B：Snowflake + 号段混合（号段内嵌worker_id）
   - 默认用方案A，代码中两种都实现
3. 容灾设计：
   - DB不可用时，使用本地Snowflake降级
   - 号段剩余量低时提前告警
   - 实例故障时其他实例接管其号段
4. 部署方案：
   - docker-compose启动3个ID服务实例
   - Nginx负载均衡
   - 每个实例注册不同的worker_id
5. 集成测试：
   - 3个实例并发生成ID，汇总验证全局唯一性
   - 模拟一个实例宕机，验证其他实例正常工作

提供docker-compose.yml和Nginx配置。

验证清单

• 3个实例自动分配不同worker_id
• 各实例生成的ID全局无重复
• 实例宕机后心跳超时被清理
• DB不可用时降级到Snowflake

你学到了什么

• 分布式worker协调 → Module: 服务注册与发现
• 心跳机制和故障检测 → Module: 分布式健康检查
• 降级策略的层次设计 → Module: 容错设计

---

V6 — 10万+用户：全局ID服务

场景

公司有几十个微服务都需要ID生成，各自实现不统一。需要一个独立的ID生成微服务，多数据中心部署，高可用。

你要解决什么

构建独立的ID生成微服务，支持多数据中心部署，ID全局趋势递增。

给AI的Prompt

设计并实现全局ID生成微服务：

1. 独立微服务架构：
   - gRPC + HTTP双协议（内部gRPC，外部HTTP）
   - 每秒支持10万+ID生成
   - p99延迟<2ms
2. 多数据中心策略：
   - 每个DC分配不同的DC_ID（嵌入ID中）
   - DC内用号段模式，DC间通过DC_ID隔离
   - ID结构：DC_ID(4位) + 时间戳(41位) + worker(7位) + 序列(12位)
3. 高可用设计：
   - 每个DC至少3个实例
   - etcd做服务注册和worker ID分配
   - 主DB故障时从库自动提升
   - 极端情况：所有DB不可用，降级到本地时钟+随机数
4. SDK设计：
   - Go SDK：连接池，本地缓存一批ID，批量获取减少RPC次数
   - SDK内置重试、超时、熔断
   - 使用示例代码
5. 运维面板：
   - 各DC/实例的ID生成QPS
   - 号段消耗速度和预计耗尽时间
   - 手动扩容号段步长
6. ID规范文档：
   - 各业务线的ID格式约定
   - ID反解析工具（从ID看出DC、时间、机器）

重点实现gRPC服务和Go SDK，运维面板给出设计稿。

验证清单

• gRPC和HTTP接口都能正常生成ID
• 不同DC生成的ID全局唯一
• SDK批量获取减少了RPC调用次数
• 单实例QPS达到10万+
• ID解析能还原DC、时间、机器信息

你学到了什么

• gRPC vs HTTP的选型考量 → Module: RPC框架
• 多数据中心的ID隔离策略 → Module: 多活架构
• SDK设计原则（批量、缓存、熔断） → Module: 客户端SDK设计
• etcd在服务协调中的角色 → Module: 分布式协调