4. 热点故障的常见场景：秒杀抢购、热门榜单、微博大V发帖、直播间弹幕、全局计数器

Redis 热点故障并非偶发事件，而是特定业务模型下的必然产物。理解这些典型场景的流量特征与数据访问模式，是制定针对性排查方案的前提。本章逐一拆解五种最常见的热点场景，分析其技术本质与故障触发条件。

4.1 场景总览

下表从访问模式、数据量级、热点持续时间三个维度，对比五种典型场景的核心差异：

4.2 秒杀抢购：瞬时洪峰下的单 Key 瓶颈

秒杀抢购是 Redis 热点故障的“头号杀手”。其核心逻辑通常围绕一个库存 Key（如 seckill:stock:1001）进行原子扣减操作。当数十万用户同时点击“立即抢购”时，所有请求集中攻击同一个 Key。

秒杀场景的 Redis 端表现具有高度可识别性：

• CPU 使用率瞬间飙升至 90% 以上，单核瓶颈尤为明显。
• INFO commandstats 中 DECR/DECRBY 命令耗时占比超过 60%。
• 客户端出现大量 READONLY You can't write against a read only replica（主从切换后写入失败）。
• 慢查询日志中出现大量针对库存 Key 的 WATCH/MULTI/EXEC 事务。

# 秒杀场景下 Redis 慢查询日志示例
127.0.0.1:6379> SLOWLOG GET 5
1) 1) (integer) 42
   2) (integer) 1692000000
   3) (integer) 12000000  # 执行耗时 12ms
   4) 1) "WATCH"
      2) "seckill:stock:1001"
   5) "127.0.0.1:54321"
2) 1) (integer) 41
   2) (integer) 1692000000
   3) (integer) 11500000  # 执行耗时 11.5ms
   4) 1) "MULTI"
   5) "127.0.0.1:54322"

4.3 热门榜单：读放大效应与带宽打满

热门榜单（如微博热搜、抖音热榜）是典型的“读热点”场景。榜单数据通常存储在 ZSET 结构中，前端每秒钟轮询拉取全量榜单。当榜单内容成为全网关注焦点时，读取频率会呈指数级增长。

与秒杀不同，榜单场景的瓶颈往往不在 CPU，而在网络带宽。一个包含 50 条数据的 ZSET，序列化后约 5~10KB。当 QPS 达到 10 万时，单 Key 的带宽消耗可达 500MB/s~1GB/s，远超普通 Redis 实例的网卡上限。

榜单场景的 Redis 端特征：

• 网卡 RX/TX 流量持续高位，接近实例规格上限。
• ZRANGE/ZREVRANGE 命令调用次数占比极高，且每次返回大量元素。
• 客户端连接数正常，但请求延迟出现周期性抖动（TCP 重传导致）。
• Redis 自身 used_memory 不高，但 used_memory_rss 异常增长（内核 Socket Buffer 占用）。

4.4 微博大V发帖：写扩散与粉丝列表热点

微博大V发帖场景的 Redis 热点具有“双重性”：既是写热点，也是读热点。当拥有千万粉丝的大V发布一条新微博时，系统需要将这条微博写入所有在线粉丝的“时间线”中（写扩散），同时粉丝客户端会立即拉取最新内容（读扩散）。

该场景的核心热点 Key 是大V的粉丝列表 Key（通常存储在 SET 或 Sorted Set 中）。每次发帖时，应用层需要遍历这个粉丝列表进行推送。当粉丝列表 Key 包含数百万个元素时，SMEMBERS 或 ZRANGE 操作会阻塞 Redis 事件循环长达数秒。

# 大V粉丝列表 Key 过大导致的阻塞示例
# 假设粉丝列表 Key: fanlist:10086，包含 800 万粉丝
127.0.0.1:6379> SMEMBERS fanlist:10086
(blocked for 3.2 seconds)  # 阻塞期间所有其他请求排队
1) "user:10001"
2) "user:10002"
...
8000000) "user:9999999"

4.5 直播间弹幕：实时写入与消息队列热点

直播间弹幕场景的 Redis 热点集中在弹幕消息队列 Key 和在线人数计数器 Key。每个直播间对应一个 List 或 Stream 类型的 Key，用于存储弹幕消息。当直播间人气达到百万级别时，弹幕的写入速率可达每秒数万条。

该场景的特殊性在于：弹幕写入是持续性的，不像秒杀那样瞬间结束。长时间的高并发写入会导致：

• Redis 内存持续增长，触发 maxmemory 淘汰策略，影响其他业务 Key。
• List 的 LPUSH + LTRIM 组合操作频繁，产生大量内存碎片。
• 主从复制延迟增大，从库无法及时同步弹幕数据。
• 客户端订阅（SUBSCRIBE）连接数过多，消耗 Redis 文件描述符资源。

# 直播间弹幕场景的 Redis 内存监控
127.0.0.1:6379> INFO memory
# Memory
used_memory: 8589934592    # 8GB
used_memory_rss: 10737418240  # 10GB
mem_fragmentation_ratio: 1.25
maxmemory: 10737418240     # 10GB
maxmemory_policy: allkeys-lru

4.6 全局计数器：单 Key 竞争与性能抖动

全局计数器场景（如网站 PV/UV 统计、API 调用次数、每日签到人数）看似简单，却隐藏着不易察觉的热点问题。计数器通常使用 INCR 或 INCRBY 命令操作单个 Key，当并发量达到一定阈值时，单 Key 的写入竞争会导致性能抖动。

与秒杀场景不同，全局计数器的 QPS 通常不会瞬间爆发，而是持续稳定在高位。这种“温水煮青蛙”式的热点，往往在业务量增长到某个临界点后才突然暴露。

全局计数器场景的 Redis 端特征：

• CPU 使用率缓慢上升，而非瞬间打满。
• INCR 命令的平均耗时从 0.1ms 逐渐增长到 1ms 以上。
• Redis 的 instantaneous_ops_per_sec 并未明显增加，但延迟却在恶化。
• 排查时容易误判为网络问题，实际是单 Key 的原子操作串行化导致。

4.7 场景对比与排查优先级

在实际故障排查中，不同场景的排查切入点差异很大。下表总结了各场景的首选排查命令与关键指标：