分布式 ID

分布式 ID 基础概念 & 数据库自增 ID 痛点

分布式 ID 基础

什么是分布式 ID

分布式系统全局唯一主键，用来替代单库自增 ID。 四大硬性要求：

1. 全局唯一：多节点、多库生成 ID 绝不重复
2. 趋势有序：整体按时间递增，优化数据库索引
3. 高性能：高并发场景生成速度快，无阻塞
4. 可扩容：机器扩容后 ID 生成规则不用大幅改动

项目使用场景（短信平台）

1. 单条短信任务 ID：日志追踪、幂等去重、下发状态排查
2. MQ 消息 messageId：解决消息重复投递，消费幂等
3. 营销活动、流水记录全局主键

数据库自增四大痛点梳理

1. 分库分表场景，每个库自增起点一致，ID 重复，无法保证全局唯一
2. 单库自增有写入性能瓶颈，短信群发、秒杀等高并发场景扛不住
3. ID 连续递增，外部可推算业务订单 / 短信总量，存在数据泄露风险
4. 仅适配单体架构，多服务分布式集群无法兼容，扩展性差

痛点 1：分库分表后 ID 重复，无法全局唯一

场景说明

短信业务数据量大，短信流水表会做水平分表，比如按月份拆分sms_log_202607、sms_log_202608两张表。 每张独立表的自增主键都是从 1 开始自增。

• 7 月表第一条短信 ID=1，8 月表第一条短信 ID 也 = 1；
• 若业务需要通过 ID 全局查询任意一条短信，会查到多条数据，主键失去唯一性；
• 多服务多数据库实例同时插入数据，相同 ID 冲突，插入报错，业务流程中断。

痛点 2：单库自增存在性能瓶颈，扛不住高并发群发

场景说明

营销活动大批量群发短信，瞬时上万请求同时写入短信记录表。 数据库自增主键底层需要锁表 / 锁行保证自增有序，并发越高，锁竞争越激烈：

• 大量线程排队等待获取自增值，接口响应变慢；
• 极端并发下数据库 CPU、IO 打满，出现超时、消息下发失败；
• 单库写入能力有上限，无法支撑大促、短信轰炸类瞬时流量。

痛点 3：ID 连续递增，容易推算业务总量，存在数据泄露风险

场景说明

外部人员抓接口查看短信任务 ID： 第一天下发短信 ID 到 10000，第二天到 20000，可直接算出平台日均下发 1 万条短信； 竞争对手能通过 ID 增长速度推算你的客户规模、营销活动力度； 如果是订单系统，还能推算营收、单量等核心商业数据，造成商业信息泄露。

痛点 4：仅适配单体架构，分布式集群扩展性极差

场景说明

项目后期扩容，新增多台业务服务器、多套数据库实例。 原生自增规则没有区分服务节点、机器标识，新上线的数据库无法和老库统一 ID 规则：

• 不能无缝水平扩容；
• 一旦拆分集群，必须改造主键生成逻辑，改动量大、线上改造成本高；
• 不适合微服务分布式架构下多服务共用一套 ID 体系的需求。

临时兜底方案

线上紧急情况可用 UUID 临时替代，但缺点明显：无序、字符串过长、索引效率极低，只能短期应急，不能长期使用。

UUID 是随机字符串，能保证唯一，但完全违背分布式 ID「趋势有序、高性能」需求：

1. 无序，插入数据库时数据随机散落，B + 树索引频繁页分裂，写入速度暴跌；
2. 字符串长度长，占用存储空间更大，分页、检索性能差；
3. 无法从 ID 中解析时间、机器信息，短信异常排查、日志追踪完全不方便。

极简背诵口诀

分库分表 ID 重复，全局查询乱； 高并发锁竞争，群发数据库崩； 连续 ID 泄数据，对手估算业务量； 仅适配单体，扩容改造成本高。

分布式 ID 四大硬性要求

四大核心硬性标准（所有分布式 ID 方案必须同时满足）

全局唯一

多服务、多数据库、多节点同时生成 ID，绝对不能重复。

落地价值：短信任务 ID、MQ 消息 ID 依靠唯一性做幂等去重，重复会导致重复下发短信、重复消费消息。

趋势有序

ID 整体随时间从小到大递增，不需要严格连续。

落地价值：存入 MySQL 时贴合 B + 树索引有序写入规则，减少索引页分裂，入库、分页查询速度更快；雪花算法依靠高位时间戳天然实现有序。

高性能

每秒能支撑超大并发生成 ID，不能出现接口阻塞、超时。

落地价值：营销批量群发瞬时上万条短信，ID 生成不能成为性能瓶颈。

可扩容

后续新增服务器、新增分库分表节点，不用大规模修改 ID 生成逻辑，简单配置即可兼容扩容。

落地价值：业务规模扩大后平滑扩容，不用重构主键体系。

反例：UUID 为什么不符合标准

1. 无序，破坏索引性能；
2. 长字符串，存储占用大；
3. 无法反推生成时间、机器，不方便短信日志排查； 仅满足「全局唯一」一条，只能临时应急，禁止长期做主键。

速记口诀

唯一防重幂等稳，有序优化索引快； 高并发不卡顿，扩容不用大改造。

方案一 雪花算法（主流首选）

适用场景

短信任务 ID、MQ 消息 messageId、订单、流水 ID，绝大多数常规高并发业务首选。

64 位二进制四段结构（高位→低位）

1. 符号位 1bit：固定 0，保证 ID 为正数，不使用；
2. 时间戳 41bit：毫秒级时间，放在高位，实现 ID 趋势有序；
3. 机器 ID 10bit：区分不同服务器，最多支持 1024 台机器，避免多节点 ID 重复；
4. 序列号 12bit：同一毫秒内自增，单台机器每毫秒最多生成 4096 个 ID。

优缺点

✅优点

1. 本地内存计算生成，无网络 IO，性能极高；
2. 时间戳在高位，趋势有序，数据库索引友好；
3. 纯数字 Long 类型，存储占用小，查询速度快；
4. 自带机器、时间信息，可追溯短信下发节点与时间，方便异常排查；
5. 无第三方中间件依赖，架构简单。

❌缺点

1. 强依赖服务器系统时间，时钟回拨会生成重复 ID，破坏幂等；
2. 10bit 机器 ID 上限 1024 台机器，集群超量需要修改位数；
3. ID 包含时间、机器信息，少量业务数据有泄露风险。

短信业务为什么优先雪花算法

1. 全局唯一，满足短信幂等、MQ 消息去重需求；
2. 有序，短信流水表索引查询更快；
3. 群发高并发场景本地生成，无 Redis 网络开销，吞吐更高；
4. 可根据 ID 反推下发时间、服务节点，快速定位下发失败、丢消息问题；
5. 仅瞬时极端流量搭配 Redis 自增兜底，常规场景完全够用。

线上避坑重点

必须手动配置唯一机器 ID；增加时钟回拨检测逻辑，时间回拨时暂停生成 ID 或等待时间追上，防止重复 ID。

速记口诀

一符二时三机器，四段序列四千六； 本地生成速度快，有序索引更顺滑； 最怕时钟往回拨，千台机器是上限。

方案二 Redis 自增 ID

适用场景

营销活动瞬时超高并发批量群发、秒杀流水、短期临时任务 ID；适合流量瞬间爆发、对 ID 有序性要求不高的场景。

实现原理

依靠 Redis 单线程执行命令的原子特性，使用INCR / INCRBY实现全局自增计数器，天然不存在并发冲突； 可拼接日期、业务前缀生成自定义格式 ID，例如 20260801000001。

优缺点

✅优点

1. 原子自增，绝对全局唯一，不会出现重复 ID；
2. 瞬时并发性能极强，支撑上万并发短信群发；
3. 代码实现简单，快速上线兜底；

❌缺点

1. 强依赖 Redis 中间件，存在网络 IO 损耗；
2. Redis 宕机 / 故障时，ID 生成功能直接不可用；
3. 单纯自增值无时间、机器信息，ID 无序，索引友好度差；

线上优化方案

1. 按业务拆分不同 Key（短信、活动分开计数），减少单 key 竞争；
2. 部署 Redis 集群保证高可用，防止单点故障；
3. 计数器设置过期时间，清理无用历史计数，节省内存。

短信业务落地搭配方案

常规群发：雪花算法做主 ID； 大促瞬时海量群发：叠加 Redis 自增方案兜底，提升瞬时吞吐。

速记口诀

Redis INCR 原子自增，瞬时并发性能猛； 群发兜底很合适，集群持久不能省； 跨机无序缺信息，宕机易重是硬伤。

方案三 数据库号段模式（稳定兜底方案）

适用业务场景

营销活动 ID、长期稳定核心业务主键；适合并发量不极端、追求架构稳定、不想额外依赖 Redis 中间件的业务。

核心实现原理

单独创建一张专用 ID 生成数据表，服务启动时批量从数据库申领一整段 ID（如 1~10000）缓存到本地内存；

业务生成 ID 直接读取内存缓存，当前号段耗尽后，再异步批量申领下一段，大幅减少数据库交互次数，降低 IO 压力。

生产优化常用双号段缓存：当前段使用到阈值，后台预加载第二段，实现无缝切换，无卡顿。

优缺点

✅优点

1. 仅依赖数据库，无需引入 Redis 等第三方组件，架构稳定；
2. 批量申领减少频繁单条 DB 请求，大幅降低数据库 IO 压力；
3. 不存在雪花算法时钟回拨、Redis 宕机 ID 不可用的风险；

❌缺点

1. 号段切换间隙会出现 ID 空洞，ID 连续性差；
2. 极端瞬时并发性能弱于雪花、Redis 自增；
3. 单库 ID 生成表存在单点压力，高并发需分库部署多张号段表。

短信业务落地定位

不作为常规短信主 ID 方案，多用于营销活动、后台稳定业务主键，做底层兜底 ID 生成方案。

速记口诀

单独建表批量领，内存缓存少 IO； 双段预载无卡顿，不靠 Redis 更稳定； 有空洞、并发弱，单表高并发要分库。

三大方案在短信项目落地选型

短信任务唯一 ID 组合方案

主方案：雪花算法 兜底方案：Redis 自增

1. 日常普通短信下发：雪花算法，有序、本地生成、索引友好，方便日志追踪与幂等；
2. 营销批量群发瞬时超大流量：叠加 Redis 自增提升瞬时吞吐；
3. 作用：每条短信唯一标识，幂等去重、下发状态回溯、异常排查。

MQ 消息 messageId 固定选型

统一使用雪花算法 ID

1. 每条异步消息携带雪花 ID 作为 messageId；
2. 消费端根据 ID 做幂等判断，解决 MQ 重复投递问题；
3. 优势：全局唯一、可追溯，完美适配消息幂等场景。

营销活动 ID 选型

数据库号段模式 活动并发平缓、追求稳定，不需要引入 Redis，使用号段生成活动主键。

三大方案综合对比速记

1. 雪花算法：综合最优，有序、无依赖、高性能 → 短信 ID、MQ 消息 ID 主力；
2. Redis 自增：瞬时并发最强，依赖中间件 → 群发流量兜底；
3. 数据库号段：稳定无第三方依赖，并发偏弱 → 营销活动 ID

选型速记口诀

短信主用雪花，群发 Redis 兜底； 消息 ID 全雪花，活动号段最省心。