4. 内存数据库：Redis核心数据结构与游戏应用（排行榜、会话、实时状态）
好，咱们进入第四章。这一章聊的是Redis，说白了就是游戏服务器的“内存加速器”。
我做了这么多年游戏后端，Redis几乎成了标配。为什么？因为游戏对实时性要求太高了。你想想看，玩家点一下排行榜，等两三秒才刷新，那体验直接崩了。Redis就是来解决这个问题的。
4.1 Redis核心数据结构速览
Redis的数据结构，我习惯把它们分成五类。每一类在游戏里都有特定的用武之地。
| 数据结构 | 底层实现 | 游戏应用场景 |
|---|---|---|
| String | 动态字符串 | 玩家会话Token、配置缓存 |
| Hash | 哈希表 | 玩家属性、实时状态 |
| List | 双向链表 | 消息队列、最近操作记录 |
| Set | 哈希表 | 在线玩家集合、每日签到 |
| Sorted Set | 跳表+哈希表 | 排行榜、定时任务 |
嗯，这里要注意。很多人以为Redis就是简单的key-value，其实它的数据结构各有各的脾气。用错了，性能反而会下降。
4.2 排行榜：Sorted Set的经典应用
排行榜，几乎是每个游戏都有的功能。我最早做排行榜时，用的是MySQL的ORDER BY。结果呢？玩家一多，查询直接超时。后来换成Redis的Sorted Set，问题就解决了。
Sorted Set的核心是“分数-成员”结构。每个成员有一个分数，Redis自动按分数排序。你想想看，这不就是排行榜的天然模型吗？
核心操作：
ZADD leaderboard 1000 "player_001"— 添加或更新玩家分数ZINCRBY leaderboard 50 "player_001"— 增加玩家分数（比如击杀加分）ZREVRANGE leaderboard 0 9 WITHSCORES— 获取前十名ZRANK leaderboard "player_001"— 获取玩家排名
我在项目中遇到过一个问题：排行榜更新太频繁，导致Redis压力大。后来我加了一层本地缓存，每5秒批量写入一次。效果立竿见影。
避坑指南：我曾经犯过一个错，直接用ZADD覆盖玩家分数。结果玩家分数被清零了。正确的做法是用ZINCRBY，只增加不覆盖。除非是赛季重置，才用ZADD重新设置。
4.3 会话管理：String与Hash的配合
玩家会话，说白了就是登录状态的凭证。我习惯用String存储Token，用Hash存储会话详情。
为什么这么分？因为Token需要快速校验，String的读写速度最快。而会话详情包含多个字段（玩家ID、登录时间、IP地址等），用Hash可以一次获取全部。
// 存储Token
SET session:token:abc123 "player_001" EX 3600
// 存储会话详情
HSET session:detail:player_001 \
token "abc123" \
login_time "2024-01-15 10:30:00" \
ip "192.168.1.100"你想想看，如果玩家掉线重连，我们只需要校验Token是否有效。有效的话，直接从Hash里取出会话详情，恢复状态。整个过程不到1毫秒。
注意：Token一定要设置过期时间（EX参数）。我见过一个项目，Token永不过期，结果被黑客利用，盗号事件频发。建议Token有效期设为1小时，玩家活跃时自动续期。
4.4 实时状态：Hash的妙用
实时状态，比如玩家当前血量、位置、技能冷却。这些数据变化快，但不需要持久化到数据库。Redis的Hash就是最佳选择。
我习惯用Hash存储玩家的实时状态，字段名就是状态名称，字段值就是状态数据。
// 玩家实时状态
HSET player:status:1001 \
hp 850 \
max_hp 1000 \
x 120.5 \
y 340.2 \
skill_cooldown 0
// 更新血量
HINCRBY player:status:1001 hp -50
// 获取全部状态
HGETALL player:status:1001嗯，这里有个小技巧。用HINCRBY更新血量，比先GET再SET快得多。因为它是原子操作，不需要两次网络往返。
实战经验：我在做MMO游戏时，每个场景有上千个玩家。如果每个玩家的状态都实时写入Redis，网络带宽会爆。我的方案是：玩家状态变化时，先缓存在本地，每100毫秒批量写入一次。这样既保证了实时性，又降低了网络开销。
4.5 综合案例：一个简单的排行榜系统
咱们来写一个完整的排行榜系统。假设游戏有击杀排行榜，玩家每击杀一个敌人，分数加10。
// 玩家击杀敌人
function onPlayerKill(playerId) {
// 增加分数
redisClient.zincrby("kill_rank", 10, playerId);
// 更新玩家击杀数
redisClient.hincrby("player:" + playerId, "kills", 1);
}
// 获取排行榜前十
function getTop10() {
return redisClient.zrevrange("kill_rank", 0, 9, "WITHSCORES");
}
// 获取玩家排名
function getPlayerRank(playerId) {
return redisClient.zrevrank("kill_rank", playerId);
}你看，代码就这么几行。但性能呢？每秒可以处理几万次击杀事件。这就是Redis的魅力。
避坑指南：我曾经在排行榜里存了玩家昵称，结果玩家改名后，排行榜数据就乱了。正确的做法是只存玩家ID，昵称从数据库或缓存里取。这样改名不影响排行榜。
4.6 总结与建议
Redis的核心数据结构，说白了就是五种：String、Hash、List、Set、Sorted Set。每种都有它的脾气和用途。
- 排行榜：用Sorted Set，分数就是排序依据
- 会话管理：String存Token，Hash存详情
- 实时状态：Hash存全部状态，HINCRBY做原子更新
- 在线集合：Set存在线玩家ID，方便做交集、并集运算
我个人建议，刚开始用Redis时，不要贪多。先把String和Sorted Set用好，这两个就覆盖了80%的游戏场景。等熟练了，再慢慢探索其他数据结构。
嗯，这一章就到这里。下一章咱们聊聊Redis的持久化策略，这可是个坑，我踩过好几次。