Q29: Redis 在 MMO 中有哪些应用场景？
核心结论
Redis 适合做高频访问、低延迟、可接受内存成本的数据层，但它不是 MMO 的万能主存储。
更合理的定位通常是：
- 缓存层
- 排行榜与计数器层
- 分布式协调与轻量状态层
- 短期消息或任务中转层
把 Redis 当成所有业务的唯一真相来源，后面往往会为持久化、审计和一致性付出很大代价。
一、Redis 最适合解决什么问题
Redis 的优势主要在：
- 低延迟读写
- 丰富数据结构
- 原子操作方便
- 适合热点数据
所以它非常适合那些：
- 访问频繁
- 结构不复杂
- 可以接受内存型存储成本
- 需要快速聚合或排序
的数据场景。
二、MMO 里常见应用场景
1. 排行榜
这是最经典的应用之一。
原因很简单：
- 排名查询频繁
- Top N 查询天然适合有序集合
- 分数更新相对直接
2. 在线状态和轻量会话信息
例如：
- 是否在线
- 在线网关
- 最后活跃时间
- 简单场景标记
这类数据更新频繁、读取也频繁，很适合用 Redis 承接。
3. 热点缓存
例如：
- 玩家基础资料摘要
- 公会摘要信息
- 活动配置
- 热门交易品价格
它的关键价值是挡住数据库热读。
4. 计数器和限流
例如：
- 登录限流
- 接口频率限制
- 活动参与次数
- 全服统计计数
5. 分布式协调
例如：
- 简单锁
- 任务占位
- 幂等标记
- 节点心跳摘要
但这里要克制，别把复杂协调全部塞进 Redis 脚本里。
三、不适合直接全交给 Redis 的场景
1. 高价值资产主账
例如：
- 货币最终账本
- 道具主存档
- 交易成交主记录
这类数据更需要：
- 持久化可靠性
- 审计流水
- 明确事务边界
Redis 可以辅助，但不应轻易成为唯一真相来源。
2. 复杂查询和报表
涉及多条件过滤、聚合分析、历史报表时，关系型数据库或 OLAP 系统通常更合适。
3. 大对象冷数据
低频访问的大对象长期放在内存里，成本通常不划算。
四、Redis 用好了很强，用不好也很危险
常见风险包括：
- 热 key
- 大 key
- 缓存雪崩
- 持久化抖动
- 把缓存写成主库
尤其是排行榜、热门活动、全服统计，很容易出现单 key 过热问题。
五、工程上更稳妥的使用方式
一个常见组合是：
- MySQL 或其他持久层保存主档
- Redis 承担热点读、排行榜、会话和短期状态
- 关键修改以数据库或可靠流水为准
- Redis 数据可重建或可回填
这会让系统在 Redis 波动时更容易恢复。
六、常见误区
1. Redis 很快，所以所有数据都该放进去
不对。快不代表适合作为所有业务的权威存储。
2. 有持久化就可以当数据库主库
Redis 的持久化能力和关系型数据库的事务、索引、审计目标并不相同。
3. 分布式锁解决一切并发问题
很多问题更适合单权威写入或状态机约束，而不是到处加锁。
参考资料
- Redis 官方文档
- 各类在线游戏 Redis 排行榜、热点缓存与在线状态实践资料