基于 Redis 实现大规模游戏排行榜

为吸引游戏玩家，排行榜是游戏应用中常见的场景，您可以通过本文档了解在大规模游戏应用场景下，实时排行榜和历史排行榜的实现方法。
前提条件
• 已创建较大规格的企业版云数据库Redis实例。
• Redis实例与应用所部署的ECS实例在同一VPC中，或者同属经典网络且在同一地域。
• 已将ECS实例的内网IP地址设置到Redis实例的白名单中。
背景说明
按排行榜时效性来划分分，排行榜可以分为实时榜和历史榜。实时榜常见于玩家完成游戏后出现的实时榜单，比如玩家积分榜，玩家区排名榜。历史榜常见于定期更新的榜单，比如日榜单，周榜单，月榜单。
好友实时排行榜

当用户规模较小的时候，利用Redis 中的sorted set和hmap数据结构就可以快速支持这种排序场景。
Key对应排行榜名称，member对应具体的用户或属性项，score对应分数。用ZADD加入用户数据，用ZRANGE或ZRANGEBYSCORE 来获取排序列表。
redis -> zadd friends_rank 1620 userA
redis -> zrange friends_rank 0 10
但一旦游戏应用达到一定规模，这种实现就会受到性能的挑战，和以下我们详细介绍一下这类排行榜的实现细节。
场景案例
场景需求
• 展示本区全量的游戏玩家日排名，游戏玩家数在十万级别，列表展示需要具备一定的容错功能。
• 需实时展示本玩家的排名情况。
场景分析
上述场景需求需要关注以下几个点：
• 游戏玩家在十万级别，因此单个sorted set 来完成过于庞大，要考虑拆分来平衡性能。
• 这么大量级的排行榜，用户对实时排行榜的敏感度并不高，因此容错功能可以考虑采用前一天的数据作为保底数据。
• 要获取每个玩家的排名信息，都需要读取这个排行榜，这意味着排行榜会成为一个热点数据，设计的时候需要注意如何规避。
功能设计
通过以上场景分析，我们先考虑总排行榜的数据存储问题。如果将 100000 条数据全部存储在一个 sorted set 里面，这时会实例的性能会产生很大的影响。因此我们考虑将排行榜按 Score 值区间拆分10个，这样也有利于 Top N数据的读取。
由于排行榜数据会被覆盖，出于容错考虑，我们设计了AB两个排行榜，当A排行榜处于 Online 状态时，数据会更新到该排行榜，展示时总是从 Online 状态的排行榜获取。排行榜的状态每日一次切换，这样如果当天有异常，可以先切换到Offline的排行榜上，展示近一天的数据。
在单个玩家排名上，我们先计算好每个玩家的排名信息，并将其存入TairHash结构中。这样获取每个用户排名的访问就能散列在各个Hash结构中，而不会形成热点。这里选用 TairHash（https://help.aliyun.com/document_detail/145970.html），而不是 Redis 原生的 Hashes 结构，主要是因为 TairHash 具有过期失效的功能。玩家的排名信息最多只需要两天，因此我们只需要设置2天的过期时间即可满足需求，不需要造成额外的资源浪费和开发成本。

以下我们详细说明一下各功能的设计要点：
总排行榜展示（每页50个）
rank_count = ZCARD Region_Rank_A1 # 获取score最大的Rank Zset的长度
start = 0
step = 50
end = 0
index = 0
while (rank_count > end)
end = start + step * index
ZRANGE Region_Rank_A1 start end # 按 50 个分页获取排行榜信息
index ++
单个用户加入
Zadd Region_Rank_A1 2 userA #加入 Score 为2 的用户A
单个用户排名

先获取该用户在本Rank Zset里面的排名

user_cur_rank = ZRank Region_Rank_An 2

再加上前面Rank Zset的长度，即为该用户总排名

user_rank = user_cur_rank + ZCARD(Region_Rank_An-1) + ZCARD（Region_Rank_An-2）+ … + ZCARD（Region_Rank_A1）

写入 TairHash 结构，该结构具有过期功能

exHSET userA today user_rank EX 86400
exHGET userA today
总结
Redis 丰富的数据结构可以简单快速地实现排行榜场景，即使在大规模数据的场景下，借鉴数据库分库分表的思想，也可以让业务在性能和可用性上取得良好的平衡。