3、NoSQL数据库选型：Redis、MongoDB、Cassandra，各自适用场景
聊到游戏服务器的数据存储，很多新手第一反应就是「用MySQL啊」。嗯，关系型数据库确实能搞定大部分场景，但做游戏后端久了你会发现——有些数据用关系型存，简直就是拿牛刀杀鸡，或者反过来，拿鸡刀杀牛。
我个人习惯把游戏数据分成三类：热数据、温数据和冷数据。热数据要求毫秒级响应，比如玩家背包、在线状态；温数据可以接受秒级延迟，比如排行榜、聊天记录；冷数据嘛，归档就行。这三类数据，正好对应了三种不同的NoSQL方案。
Redis：热数据的首选
Redis，说白了就是一个跑在内存里的键值数据库。我最早接触它是在做MMO的聊天系统时，那时候MySQL扛不住每秒几千条的写入，换Redis后，CPU占用直接降了80%。
适用场景：
- 玩家在线状态：用SET/GET存个「online:10001 = 1」，查询速度是纳秒级的。
- 排行榜：Sorted Set天然支持按分数排序，我做过一个万人排行榜，每次更新只需要O(logN)复杂度。
- 限流与计数器：INCR命令配合过期时间，轻松实现接口防刷。
- 分布式锁：SETNX + Lua脚本，解决多服务器抢资源的问题。
- 缓存层：把MySQL的热数据缓存到Redis，减少数据库压力。
核心优势：速度快，数据结构丰富（String、Hash、List、Set、Sorted Set），支持持久化。
注意：Redis是单线程模型，虽然快，但别用它存大key。我曾经遇到过有人把整个玩家装备列表塞进一个Hash里，结果查询时阻塞了其他所有操作——嗯，血的教训。
MongoDB：文档型数据库的王者
MongoDB存的是JSON-like的文档，说白了就是「存对象」。你想想看，游戏里的玩家数据——等级、装备、技能、任务进度——天然就是一个嵌套的JSON结构。用MySQL你得拆成五六张表，用MongoDB一个文档搞定。
适用场景：
- 玩家档案：每个玩家一个文档，字段随意扩展，不用像MySQL那样先ALTER TABLE。
- 游戏日志：战斗日志、行为日志，写入量大但查询条件灵活。
- 配置表：游戏策划经常改配置，MongoDB的schema-less特性让迭代变得轻松。
- 排行榜快照：定时把Redis的排行榜数据dump到MongoDB，方便历史查询。
我的经验：做SLG游戏时，我们用MongoDB存玩家的城池数据。一个城池包含建筑、部队、资源、科技，嵌套了四五层。如果用MySQL，光JOIN就能让你怀疑人生。MongoDB的聚合管道虽然也有学习成本，但比写SQL JOIN舒服多了。
不过要注意，MongoDB的写入锁是库级别的（早期版本），高并发写入时会有性能瓶颈。现在WiredTiger引擎改成了文档级锁，但如果你还在用MMAPv1引擎，赶紧升级吧。
Cassandra：写多读少的场景利器
Cassandra的设计哲学跟Redis和MongoDB完全不同。它来自Facebook，最初是为了解决收件箱搜索问题。说白了，Cassandra就是为「写入」而生的——它的写入性能是线性扩展的，加节点就能扛更多写入。
适用场景：
- 游戏行为日志：玩家每次操作都产生一条日志，写入量巨大，但查询频率低。
- 聊天记录：全服聊天、公会聊天，每秒几千条写入，Cassandra轻松应对。
- 时序数据：比如玩家在线时长统计、经济系统监控。
- 跨地域部署：Cassandra支持多数据中心复制，适合全球同服的游戏。
核心优势：写入性能极强，无单点故障，支持水平扩展。
避坑指南：我曾经在一个项目中用Cassandra存玩家好友关系，结果发现查询「我的好友列表」非常慢。为什么？因为Cassandra的查询必须基于主键，而好友关系需要双向查询。后来我们改成了用Redis存好友列表，Cassandra只做持久化备份——嗯，选型时一定要想清楚查询模式。
三种数据库的对比
| 特性 | Redis | MongoDB | Cassandra |
|---|---|---|---|
| 数据模型 | 键值对 | 文档（JSON） | 宽列存储 |
| 读写性能 | 读极快，写快 | 读写均衡 | 写极快，读一般 |
| 扩展方式 | 主从/集群 | 分片 | 一致性哈希 |
| 持久化 | RDB/AOF | WiredTiger | Commit Log |
| 典型容量 | GB级（内存） | TB级 | PB级 |
| 学习曲线 | 低 | 中 | 高 |
实际项目中的组合策略
说实话，我很少只用一种NoSQL。大多数游戏项目都是混合使用的：
// 一个典型的游戏数据存储架构
// 热数据层：Redis
player_online_status = Redis.get("online:10001")
player_bag = Redis.hgetall("bag:10001")
// 温数据层：MongoDB
player_profile = MongoDB.find({uid: 10001})
guild_info = MongoDB.find({guild_id: "G123"})
// 冷数据层：Cassandra
battle_logs = Cassandra.execute(
"SELECT * FROM battle_log WHERE uid = 10001 AND time > ?",
[timestamp]
)
我建议的选型原则是：
- 需要极快响应（毫秒级）→ Redis
- 数据结构复杂、经常变化 → MongoDB
- 写入量巨大、查询简单 → Cassandra
- 需要事务和强一致性 → 还是用MySQL吧，别硬上NoSQL
一个小技巧：做游戏服务器时，我习惯把Redis当作「主存储」来用，MongoDB或Cassandra只做持久化备份。这样玩家体验最好——毕竟没人愿意等500ms去打开背包。但代价是，如果Redis挂了，你会丢失几秒的数据。嗯，这就要看你的业务能不能接受了。
最后说一句，没有银弹。Redis再快，也存不下全服玩家的聊天记录；Cassandra写入再强，也做不了复杂的聚合查询。选型之前，先想清楚你的数据长什么样、怎么读怎么写、能接受多长的延迟。想明白了，选型就是水到渠成的事。