Q33: 如何处理热点数据？

核心结论

热点数据的问题，本质上不是“缓存命中率低”，而是“同一批数据在短时间内被过多请求集中打爆”。

处理热点要先分清是哪一种热点：

• 读热点
• 写热点
• 混合热点
• 突发热点

不同热点的解法差别很大，不能一律回答“上 Redis”。

一、热点数据通常长什么样

在线游戏里常见的热点包括：

• 排行榜 Top 数据
• 热门活动状态
• 公会摘要
• 登录阶段的玩家基础资料
• 热门拍卖品或市场价格

它们的共同特点是：

• 很多人同时访问
• 访问模式高度集中

二、先分读热点和写热点

1. 读热点

典型特征：

• 大量查询同一批数据
• 写入不算频繁

常见解法：

• 本地缓存
• Redis 缓存
• 预热
• 读写分离

2. 写热点

典型特征：

• 很多请求同时修改同一份状态

例如：

• 世界 Boss 伤害累计
• 活动积分榜
• 抢购库存

这类问题更需要：

• 单权威写入
• 分片聚合
• 队列串行化

光加缓存通常没用。

三、混合热点最难

既大量读，又高频写的数据最容易出问题。

例如：

• 实时排行榜
• 热门市场价格
• 热门公会状态

这类数据往往需要：

• 读写分层
• 局部缓存
• 异步聚合
• 降低展示实时性要求

四、缓存不是万能药

缓存对读热点非常有效，但对写热点要谨慎。

原因很简单：

• 热 key 仍可能把单点 Redis 打爆
• 高频失效会形成抖动
• 多写入口会放大一致性问题

所以热点治理的第一步通常不是“先缓存”，而是“先减少不必要访问和写入”。

五、常见治理手段

1. 多级缓存

适合读热点：

• 进程内缓存挡住最热读
• Redis 承接共享缓存
• 数据库作为最终持久层

2. 分片和分桶

适合写热点或大规模聚合：

• 按玩家、分区、时间窗口拆散
• 后续再做汇总

3. 单写者模型

让某类热点数据只由一个权威节点修改，其他节点只读或异步同步。

4. 降频和快照化

不是所有热点都必须毫秒级实时。

很多展示型数据可以：

• 每几秒刷新一次
• 批量合并更新
• 只显示最近快照

六、热点数据为什么常和架构问题绑在一起

因为热点往往不只是数据本身热，而是系统把所有请求都导向同一个写点或读点。

所以真正要看的是：

• 是否有单点写入口
• 是否有单 key 聚合
• 是否每个请求都必须查同一对象

很多所谓热点问题，本质上是系统边界设计问题。

七、工程上更稳妥的思路

常见组合是：

• 读热点走多级缓存
• 写热点走单权威更新或队列聚合
• 展示数据允许短延迟
• 热 key 做拆分或局部汇总
• 关键结果保留持久化真相来源

八、常见误区

1. 热点问题就是数据库太慢

很多时候真正的热点已经在缓存层甚至应用层形成了。

2. 所有热点都能靠 Redis 解决

读热点常常可以，写热点和混合热点未必。

3. 热点数据必须完全实时

很多展示型热点可以接受快照或秒级延迟，这往往更划算。

参考资料

• 各类在线游戏热点缓存、热 key 治理与聚合写入实践资料