应用场景

分布式 ID 生成器在现代互联网系统中有着广泛的应用。让我们从真实的故事开始，了解为什么需要分布式 ID。

故事背景

2023年，小红书正经历着爆发式增长。随着用户量突破1亿，订单量激增，技术团队发现了一个严重的问题：

• 订单号重复
• 用户 ID 冲突
• 消息追踪 ID 丢失
• 数据库主键冲突

这些问题导致：

• 支付失败
• 用户投诉激增
• 数据不一致
• 系统稳定性下降

常见应用场景

1. 订单号生成

场景描述：电商系统中的订单号需要全局唯一，且最好能按时间有序。

业务需求：

• 全局唯一：绝对不能重复
• 有序性：最好按时间递增，便于查询和排序
• 可读性：部分业务场景需要可读的订单号
• 安全性：不能轻易推测下一个订单号

示例：

订单号示例：20240410123456789
- 前缀：日期 20240410
- 后缀：8位唯一数字

2. 用户 ID 分配

场景描述：在分布式系统中为新注册的用户分配唯一用户 ID。

业务需求：

• 全局唯一：用户 ID 必须唯一，不能冲突
• 数值型：便于数据库索引和存储
• 递增性：便于用户管理和数据统计
• 长度固定：便于前端展示和API设计

示例：

用户ID示例：10000001
- 数值型：10000001
- 便于存储和查询

3. 消息追踪 ID

场景描述：在微服务架构中追踪一个请求在多个服务间的流转。

业务需求：

• 全局唯一：每个请求有唯一标识
• 生成快：不增加请求延迟
• 可携带：能在 HTTP Header 中传递
• 可读性：便于问题排查

示例：

Trace ID示例：550e8400-e29b-41d4-a716-446655440000
- UUID格式
- 跨服务追踪

4. 分布式事务 ID

场景描述：在分布式事务中标识一个全局事务。

业务需求：

• 全局唯一：事务 ID 必须唯一
• 有序性：便于事务日志管理
• 长度适中：不占用过多存储空间
• 生成快：不增加事务开销

示例：

事务ID示例：TX-20240410-1234567890
- 前缀：TX 表示事务
- 中间：日期
- 后缀：唯一数字

5. 日志追踪 ID

场景描述：在海量日志中快速定位特定请求的所有日志。

业务需求：

• 全局唯一：每个日志条目有唯一标识
• 快速生成：不影响日志性能
• 可搜索：便于日志分析系统索引
• 可关联：能关联到对应的业务 ID

示例：

Log ID示例：LOG-202404101234567890
- 前缀：LOG 表示日志
- 中间：时间戳
- 后缀：唯一序列

6. 支付流水号

场景描述：支付系统中需要唯一的支付流水号。

业务需求：

• 绝对唯一：支付流水号绝对不能重复
• 不可预测：防止被恶意推测
• 足够长：避免碰撞概率
• 可追溯：能追踪支付全流程

示例：

支付流水号示例：PAY-20240410-ABC123XYZ789
- 前缀：PAY 表示支付
- 日期：便于按日期统计
- 随机部分：保证不可预测

7. 聊天消息 ID

场景描述：即时通讯系统中的每条消息需要唯一 ID。

业务需求：

• 全局唯一：消息 ID 不能重复
• 时间有序：便于按时间排序显示
• 生成快：不影响聊天体验
• 短小精悍：减少网络传输

示例：

消息ID示例：MSG-1712701200-12345
- 前缀：MSG 表示消息
- 时间戳：便于排序
- 序列号：同一时间内的区分

8. 分库分表 ID

场景描述：在分库分表场景下作为主键。

业务需求：

• 全局唯一：跨分片唯一
• 数值型：便于分片路由
• 递增性：便于范围查询
• 分布式：多节点同时生成

示例：

分片ID示例：1234567890123456789
- 19位长整型
- 包含分片信息

业务需求总结

从以上场景可以看出，分布式 ID 的核心需求包括：

下一步

了解了应用场景后，接下来我们要分析实现分布式 ID 的技术挑战。

👉 下一节：技术挑战