Redis玩游戏字段设计那些事儿，怎么搞才更顺手更高效

（引用来源：作者“码农桃花源”在知乎专栏《Redis实战心得》中的分享）

今天咱们不聊那些高大上的理论，就坐下来，像朋友一样唠唠嗑，说说用Redis设计游戏里的各种字段时，那些让你觉得“顺手”和“高效”的小门道，Redis这东西，速度快是快，但你要是瞎用，就像开跑车走泥巴路,再好的引擎也白搭。

第一件事儿：想清楚你的数据怎么“读”和怎么“写”

在设计任何一个字段之前，你先得扪心自问：这数据，是写的多还是读的多？读的时候，我一次要读多少？这决定了你用什么数据结构。

玩家的基础信息，像等级、金币、钻石（引用来源：常见手游设计模式），这东西肯定是读远多于写，你每次打开角色面板，这些数据都要显示，但玩家升级或者充值获得钻石，写的频率相对低很多，这种场景，用一个简单的HSET，把玩家ID作为key，然后把等级、金币这些作为field和value存成一个哈希表，就非常合适，为啥？因为你一次HGETALL就能把整个面板的数据全拿回来，只需要一次网络IO，高效！你要是把等级、金币分别存成不同的String键，那你要读好几次,网络开销就大了。

反过来，如果是玩家的邮件系统（引用来源：作者在项目《星际远征》中的实际设计经验），玩家收邮件是写一次（服务器发），但读可能就一次（玩家点开看），然后可能就是删除了，邮件列表需要分页查询，这时候，你用List或者ZSet（有序集合）就更棒了，特别是ZSet，你可以用时间戳作为分数，这样既能按时间顺序排列，又能很方便地实现分页，用ZREVRANGE命令就能搞定，你要是用哈希表存所有邮件,想分页可就费劲了。

第二件事儿：别让Key长得亲妈都不认识，但也别太“短小精悍”

Key的设计是门艺术，你得让人一眼能看出来这key是干嘛的，比如存玩家数据的key，你别就弄个p:123，谁知道这是啥？过俩月你自己都忘了，你可以设计成player:123:base_info，清晰明了，player是业务模块，123是玩家UID，base_info表示这是基础信息。

也别太长！game_server_zone_1_player_data_basic_info_for_user_123这种key就太啰嗦了，浪费内存不说，你在命令行里打起来都费劲,在可读性和长度之间找个平衡。

还有个秘诀（引用来源：Redis官方文档关于Key设计的建议）：用冒号来分隔层级，这是一种不成文的规范，很多Redis管理工具会自动帮你做树状展开,看起来特别舒服。

第三件事儿：对付那些经常变、又要及时同步的数据，试试“打包”和“过期”

游戏里有一种典型数据，比如玩家的实时状态：当前位置坐标、血量、蓝量，这东西变化太频繁了，如果你每次变化都直接写Redis，Redis可能被你写趴下，但你又需要它能被其他服务（比如地图服务）快速查到。

这时候，可以考虑“打包”更新，别血量变一次写一次，坐标变一次写一次，你可以设一个定时器，比如每100毫秒，或者当状态变化累积到一定次数时，再把这一批变化一次性用HMSET命令更新到Redis里,这样能大幅减少写操作的压力。

像玩家登录后的会话信息（Session），或者一些限时活动数据，一定要记得设置过期时间（TTL），用EXPIRE命令，不然玩家下线了，这些数据还永远留在Redis里，就成了垃圾数据，时间一长，内存就爆了，设个过期时间，让Redis自动帮你清理,省心省力。

第四件事儿：排行榜是Redis的亲儿子，但细节决定成败

排行榜是Redis最经典的应用场景，用ZSet简直不要太爽,但这里也有坑。

第一个坑，如果排行榜分数一样，Redis会按成员名字典序排，这可能导致两个分数相同的玩家，名字奇怪的排前面，如果你希望分数相同时，按达到时间先后排，怎么办？（引用来源：Stack Overflow上关于Redis排序的经典问题）一个小技巧是，设计分数的时候，不要只存游戏里的得分，你可以把分数做成一个复合分数：真实分数 * 10000000000 + (9999999999 - 时间戳)，这样，分数大的依然排前面，当分数相同时，时间戳小的（即先达到的）实际复合分数更大，就会排前面，这个倍数要足够大，确保真实分数不同时,时间戳的影响可以忽略。

第二个坑，排行榜取全球Top100很快，但如果你想查某个玩家在全球排第几名，用ZRANK命令，如果整个集合很大，这个操作可能会有点慢（复杂度O(log N)），要根据业务需求来，如果不是非要实时展示全球精确名次，可以只做分段显示，您位于前1%”,或者缓存Top1000的名次。

最后唠叨两句：关于原子性和持久化

游戏里经常有“扣金币，同时给道具”的操作，这必须是一个原子操作，不能扣了金币没给道具，Redis的事务（MULTI/EXEC）或者Lua脚本能帮你搞定这个，尤其是Lua脚本，强烈推荐（引用来源：Redis官方对Lua脚本的推崇），你把逻辑写在Lua脚本里，一次性送到Redis服务器执行，保证原子性,而且减少了网络往返。

至于持久化，你知道有这么回事就行：Redis有RDB快照和AOF日志两种方式，默认配置可能不适合生产环境，起码要把AOF打开，不然服务器一断电，最近几分钟的数据就没了，玩家可是要骂娘的，具体配置可以交给运维同事，但你自己得知道数据不是绝对安全的,根据游戏类型设计一些补偿机制是明智的。

用Redis做游戏字段设计，核心就是“因地制宜”，别拿着锤子看什么都像钉子，多想想你的数据是怎么活的，怎么被用的，然后为它挑选最合适的“家”，一开始多花几分钟想清楚，后面能省下无数填坑的时间，希望这些实实在在的经验,能让你搞得更顺手更高效。