号段缓存

性能瓶颈的真相

我以为 Redis INCR 已经足够快了，直到那次压力测试。

那是周二的下午，我正在做 10 万 QPS 的压测。短链接服务的各项指标都很好——响应时间在 5ms 以内，CPU 和内存也正常。但 Redis 的监控曲线让我皱起了眉：

Redis QPS: 98,000/s
Redis 延迟: P99 从 1ms 飙升到 15ms

问题很明显：每次生成都要走一次 Redis。在高并发时，网络往返成了最大的开销。即使 Redis 本身够快，但每次调用都要：

1. 序列化请求
2. 发送到 Redis
3. Redis 执行 INCR
4. 序列化响应
5. 返回给应用

这 5 步加起来，单次可能只要 0.5ms，但乘上每秒 10 万次，就成了巨大的负担。

更重要的是，这让我的系统高度依赖 Redis。如果 Redis 抖一下，整个 ID 生成都受影响。

我需要减少对 Redis 的依赖。

号段缓存的思想

我开始研究业界的方案，看到了美团技术团队的 Leaf 项目。他们的思路让我眼前一亮：

不是每次取一个 ID，而是一次取一批。

就像我去超市买东西——不是每需要一件东西就跑一趟超市，而是一次买一周的量放在家里慢慢用。

传统模式（每次 1 个 ID）：
  我 → Redis: "给我 1 个 ID" → 1
  我 → Redis: "给我 1 个 ID" → 2
  我 → Redis: "给我 1 个 ID" → 3
  ...（每次都要网络往返）

号段模式（每次取一批）：
  我 → Redis: "给我 1000 个 ID" → 1~1000
  我在本地分配: 1, 2, 3, ..., 1000
  用完后 → Redis: "再给我 1000 个" → 1001~2000

这样的好处显而易见：

99% 的 ID 生成都变成了纯内存操作，性能提升会是数量级的。

实现号段分配器

我决定实现一个号段分配器。先用最简单的方案——单号段。

数据库设计

我把 Redis 换成了数据库，因为数据库更可靠，而且号段模式下请求次数极少：

数据设计要点

• 核心是在 id_segment 里保存业务事实，而不是把规则散落在应用逻辑里。
• 写入时要保证短码唯一、字段完整，并为后续查询留下必要状态。
• 更新操作通常意味着链接状态变化，要同步考虑缓存刷新和审计记录。
• 关键字段包括 biz_tag、max_id、step、version、updated_at、INSERT，它们决定了后续查询和管理能力。

这里的关键是 max_id 字段。它表示”已经分配出去的最大 ID”，所以下一个号段从 max_id + 1 开始。

第一版：单号段实现

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

这个实现的核心是 乐观锁。通过 version 字段保证多个实例同时请求时，只有一个能成功抢到号段：

数据设计要点

• 更新操作通常意味着链接状态变化，要同步考虑缓存刷新和审计记录。

如果 affected 是 0，说明被别人抢先了，重新读取并重试。

性能测试

我跑了压测，结果让我兴奋：

单号段模式性能：
- QPS: 95,000/s（纯内存操作）
- 数据库请求：约 95 次/秒（每 1000 个 ID 一次）
- 响应时间 P99: 2ms

对比之前的 Redis 方案：
- QPS: 70,000/s
- Redis 请求：70,000 次/秒
- 响应时间 P99: 15ms

性能提升了约 35%，数据库压力减少了 99%！

更重要的是，系统更加稳定了。因为 99% 的 ID 生成是纯内存操作，不再依赖外部系统。

号段用完时的惊险

但第一版上线后，我很快发现了问题。

有次查看监控，我发现每隔几分钟就会有 短暂的延迟尖刺：

正常请求：2ms
尖刺时刻：120ms, 85ms, 150ms...

我查看日志，发现这些尖刺都出现在 号段用完、重新加载数据库 的时候：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

在高并发时，号段用完的瞬间，所有线程都会被阻塞，等待数据库返回。虽然只有几十毫秒，但在高并发系统中，这就是一个明显的延迟尖刺。

双 Buffer 方案

我想到一个解决方案：双缓冲。

就像视频播放器的预加载——不是等到当前视频播完了再加载下一个，而是在播放到 80% 时就开始预加载下一个。

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

双 Buffer 的工作流程

时间轴：
  ┌─── 号段1（1~1000）────┐   ┌─── 号段2（1001~2000）───┐
  │                        │   │                          │
  │ 用到 80% 时触发预加载  │→  │ 异步从数据库获取          │
  │                        │   │                          │
  │ 继续使用到 100%        │→  │ 切换！无缝衔接 ✅         │
  └────────────────────────┘   └──────────────────────────┘
                                          ↓
                                用到 80% 时预加载号段3...

再跑压测，延迟尖刺消失了：

双缓冲模式性能：
- QPS: 98,000/s
- 响应时间 P99: 2ms（无尖刺）
- 数据库请求：约 98 次/秒

完美！延迟稳定，性能进一步提升。

多实例部署

号段模式天然支持多实例部署。每台服务器会取到不同的号段，不会冲突：

服务器 A：取到 1~1000
服务器 B：取到 1001~2000
服务器 C：取到 2001~3000

各用各的号段，完全不冲突 ✅

生成的 ID 序列：

实际生成的 ID 顺序：
A: 1, 2, 3, ...         ← A 的号段
B: 1001, 1002, 1003, ... ← B 的号段
C: 2001, 2002, ...       ← C 的号段
A: 4, 5, ...             ← A 继续

总体：1, 2, 3, 1001, 1002, 4, 5, 2001, ...
→ 不是严格递增，但趋势递增 ✅

Step 大小选择

号段的 step 大小需要权衡：

• 太小：频繁请求数据库，失去缓存的意义
• 太大：浪费 ID，重启后丢失大量 ID

我根据业务量计算最优值：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

最终方案

经过这些优化，我的分布式 ID 方案已经相当成熟了。但我想再进一步——如果数据库挂了呢？

虽然号段模式下数据库请求极少，但如果真的挂了，系统还是不能生成 ID。所以我加了一层保险：

号段缓存 + Snowflake fallback：

1. 优先使用号段缓存（短 ID，性能高）
2. 如果号段用完且数据库不可用，降级到 Snowflake（长 ID，但可用）
3. 监控告警，尽快恢复数据库

这样，即使数据库挂了，系统依然可以生成 ID，只是 ID 会变长，不再是连续的。

监控与告警

我加上了监控指标：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

监控仪表盘：

┌─────────────────────────────────────────┐
│ 号段模式监控                             │
├─────────────────────────────────────────┤
│ 当前号段：12,001 ~ 13,000               │
│ 已使用：78% ████████████░░░             │
│ 剩余：274 个                             │
│ 预加载状态：✅ 下一号段已就绪             │
│ 数据库请求频率：约 1 次/5 分钟            │
│ ID 生成速度：约 200 个/秒                │
└─────────────────────────────────────────┘

想一想

1. 号段模式下，如果一台服务器拿到号段后挂了，那些 ID 会怎样？（答案：丢失了，但不影响唯一性）
2. 为什么说号段模式生成的 ID 是”趋势递增”而不是”严格递增”？
3. 如果号段的 step 设太小（如 10），会有什么问题？设太大（如 1000 万）呢？

方案对比