1. 项目背景与问题起源去年接手的一个游戏运营后台项目里排行榜功能最初是用MySQL直接实现的。当同时在线玩家突破5万时系统开始出现明显的性能瓶颈。最严重的一次运营活动期间排行榜查询接口平均响应时间超过3秒高峰期直接导致数据库连接池耗尽整个服务雪崩。经过紧急扩容和临时限流措施后我们决定彻底重构这个核心功能。在对比了多种方案后最终选择基于Redis的Sorted Set数据结构实现排行榜系统。重构后排行榜查询响应时间稳定在10毫秒以内即使面对百万级用户同时刷新榜单也毫无压力。2. 技术选型与方案设计2.1 为什么选择Redis Sorted Set传统关系型数据库在排行榜这类场景下存在几个致命缺陷频繁的ORDER BY操作消耗大量CPU资源随着数据量增长索引维护成本呈指数上升高并发读写时容易产生锁竞争Redis的Sorted Set通过跳表(Skip List)哈希表的混合结构完美解决了这些问题插入/删除/查询的时间复杂度都是O(logN)元素自动按score排序无需额外计算单线程模型避免锁竞争2.2 数据结构设计要点我们为每个排行榜设计了两个核心数据结构# 玩家数据哈希表 HSET player:{uid} score 1500 name 玩家A avatar http://xxx # 排行榜有序集合 ZADD leaderboard 1500 {uid}这种分离存储的设计带来三个优势更新玩家信息时不影响排行榜性能可以灵活扩展玩家属性字段使用管道(pipeline)能保证原子性操作3. 核心实现与性能优化3.1 基础操作实现更新玩家分数def update_score(uid, new_score): with redis.pipeline() as pipe: # 更新哈希表 pipe.hset(fplayer:{uid}, score, new_score) # 更新排行榜 pipe.zadd(leaderboard, {uid: new_score}) pipe.execute()获取TOP100top100 redis.zrevrange(leaderboard, 0, 99, withscoresTrue)3.2 性能优化实践1. 内存优化配置# 调整Redis最大内存限制 config set maxmemory 4gb # 启用主动内存淘汰策略 config set maxmemory-policy allkeys-lru2. 管道批处理# 批量更新1000个玩家分数 with redis.pipeline() as pipe: for uid, score in update_items: pipe.zadd(leaderboard, {uid: score}) pipe.execute()3. 热点数据缓存对TOP100结果设置5秒本地缓存使用Redis的客户端缓存功能4. 高可用架构设计4.1 集群部署方案我们采用Redis Cluster模式部署配置要点6个节点3主3从每个主节点分配不同的哈希槽设置合理的迁移阈值# 集群创建命令示例 redis-cli --cluster create \ 192.168.1.1:6379 192.168.1.2:6379 \ 192.168.1.3:6379 192.168.1.4:6379 \ 192.168.1.5:6379 192.168.1.6:6379 \ --cluster-replicas 14.2 容灾处理策略数据持久化配置# 每5分钟生成RDB快照 save 300 1 # AOF持久化每秒同步 appendfsync everysec故障转移监控部署Redis Sentinel监控集群状态设置合理的down-after-milliseconds参数5. 实战问题与解决方案5.1 分数相同时的排序问题我们发现当多个玩家分数相同时Redis默认按字典序排序这不符合业务需求。解决方案是改造score结构# 将原始分数转换为64位长整型 def make_score(raw_score, timestamp): return (raw_score 32) (9999999999 - timestamp)5.2 大key处理经验当排行榜用户超过500万时单个ZSET会变得过大。我们采用分片方案# 按UID哈希分片 shard_id hash(uid) % 10 zset_key fleaderboard_{shard_id}5.3 冷热数据分离对于历史榜单数据每月归档一次到MySQL使用Redis的EXPIRE设置合理过期时间对超过3个月未活跃的用户移出排行榜6. 性能压测数据使用JMeter进行基准测试结果如下并发用户数平均响应时间吞吐量(QPS)错误率1008ms12,5000%100011ms90,0000%500015ms330,0000.2%测试环境配置Redis集群6台8核32G服务器网络延迟1ms测试数据量1000万用户7. 监控与告警配置完善的监控体系是稳定运行的保障关键监控指标内存使用率预警阈值80%命令延迟P9950ms触发告警连接数超过5000触发扩容Prometheus配置示例- job_name: redis static_configs: - targets: [redis1:9121, redis2:9121] metrics_path: /scrape8. 成本优化实践8.1 资源利用率提升通过分析发现夜间流量只有白天的20%运营活动期间流量突增5倍采用弹性扩缩容策略使用K8s HPA自动调整副本数设置定时扩缩容规则8.2 存储优化对玩家数据启用压缩config set hash-max-ziplist-entries 512 config set hash-max-ziplist-value 64使用更高效的序列化协议将JSON改为MessagePack格式平均减少30%存储空间9. 扩展功能实现9.1 实时增量排行榜# 记录上次查看的排名 last_rank redis.zrevrank(leaderboard, uid) # 获取排名变化 current_rank redis.zrevrank(leaderboard, uid) delta last_rank - current_rank if last_rank else 09.2 分段统计功能# 统计各分数段人数 ranges [ (0, 1000), (1001, 2000), (2001, 3000) ] for min_s, max_s in ranges: count redis.zcount(leaderboard, min_s, max_s)10. 客户端优化技巧10.1 连接池配置pool ConnectionPool( max_connections100, socket_timeout5, health_check_interval30 )10.2 智能重试机制def safe_redis_command(): retries 3 while retries 0: try: return redis.command() except RedisError: retries - 1 time.sleep(1) raise Exception(Redis operation failed)在实际运行中这套方案已经稳定支撑了日均2亿次的排行榜查询请求。最大的收获是认识到看似简单的功能背后藏着无数需要权衡的技术细节。比如在一致性方面我们最终选择了最终一致性模型通过客户端缓存和合理的过期策略在性能和准确性之间找到了最佳平衡点。 
长河君 · 2026/11/3 17:59:10 · 阅读 1.2k Redis Sorted Set实现高性能游戏排行榜系统
1. 项目背景与问题起源去年接手的一个游戏运营后台项目里排行榜功能最初是用MySQL直接实现的。当同时在线玩家突破5万时系统开始出现明显的性能瓶颈。最严重的一次运营活动期间排行榜查询接口平均响应时间超过3秒高峰期直接导致数据库连接池耗尽整个服务雪崩。经过紧急扩容和临时限流措施后我们决定彻底重构这个核心功能。在对比了多种方案后最终选择基于Redis的Sorted Set数据结构实现排行榜系统。重构后排行榜查询响应时间稳定在10毫秒以内即使面对百万级用户同时刷新榜单也毫无压力。2. 技术选型与方案设计2.1 为什么选择Redis Sorted Set传统关系型数据库在排行榜这类场景下存在几个致命缺陷频繁的ORDER BY操作消耗大量CPU资源随着数据量增长索引维护成本呈指数上升高并发读写时容易产生锁竞争Redis的Sorted Set通过跳表(Skip List)哈希表的混合结构完美解决了这些问题插入/删除/查询的时间复杂度都是O(logN)元素自动按score排序无需额外计算单线程模型避免锁竞争2.2 数据结构设计要点我们为每个排行榜设计了两个核心数据结构# 玩家数据哈希表 HSET player:{uid} score 1500 name 玩家A avatar http://xxx # 排行榜有序集合 ZADD leaderboard 1500 {uid}这种分离存储的设计带来三个优势更新玩家信息时不影响排行榜性能可以灵活扩展玩家属性字段使用管道(pipeline)能保证原子性操作3. 核心实现与性能优化3.1 基础操作实现更新玩家分数def update_score(uid, new_score): with redis.pipeline() as pipe: # 更新哈希表 pipe.hset(fplayer:{uid}, score, new_score) # 更新排行榜 pipe.zadd(leaderboard, {uid: new_score}) pipe.execute()获取TOP100top100 redis.zrevrange(leaderboard, 0, 99, withscoresTrue)3.2 性能优化实践1. 内存优化配置# 调整Redis最大内存限制 config set maxmemory 4gb # 启用主动内存淘汰策略 config set maxmemory-policy allkeys-lru2. 管道批处理# 批量更新1000个玩家分数 with redis.pipeline() as pipe: for uid, score in update_items: pipe.zadd(leaderboard, {uid: score}) pipe.execute()3. 热点数据缓存对TOP100结果设置5秒本地缓存使用Redis的客户端缓存功能4. 高可用架构设计4.1 集群部署方案我们采用Redis Cluster模式部署配置要点6个节点3主3从每个主节点分配不同的哈希槽设置合理的迁移阈值# 集群创建命令示例 redis-cli --cluster create \ 192.168.1.1:6379 192.168.1.2:6379 \ 192.168.1.3:6379 192.168.1.4:6379 \ 192.168.1.5:6379 192.168.1.6:6379 \ --cluster-replicas 14.2 容灾处理策略数据持久化配置# 每5分钟生成RDB快照 save 300 1 # AOF持久化每秒同步 appendfsync everysec故障转移监控部署Redis Sentinel监控集群状态设置合理的down-after-milliseconds参数5. 实战问题与解决方案5.1 分数相同时的排序问题我们发现当多个玩家分数相同时Redis默认按字典序排序这不符合业务需求。解决方案是改造score结构# 将原始分数转换为64位长整型 def make_score(raw_score, timestamp): return (raw_score 32) (9999999999 - timestamp)5.2 大key处理经验当排行榜用户超过500万时单个ZSET会变得过大。我们采用分片方案# 按UID哈希分片 shard_id hash(uid) % 10 zset_key fleaderboard_{shard_id}5.3 冷热数据分离对于历史榜单数据每月归档一次到MySQL使用Redis的EXPIRE设置合理过期时间对超过3个月未活跃的用户移出排行榜6. 性能压测数据使用JMeter进行基准测试结果如下并发用户数平均响应时间吞吐量(QPS)错误率1008ms12,5000%100011ms90,0000%500015ms330,0000.2%测试环境配置Redis集群6台8核32G服务器网络延迟1ms测试数据量1000万用户7. 监控与告警配置完善的监控体系是稳定运行的保障关键监控指标内存使用率预警阈值80%命令延迟P9950ms触发告警连接数超过5000触发扩容Prometheus配置示例- job_name: redis static_configs: - targets: [redis1:9121, redis2:9121] metrics_path: /scrape8. 成本优化实践8.1 资源利用率提升通过分析发现夜间流量只有白天的20%运营活动期间流量突增5倍采用弹性扩缩容策略使用K8s HPA自动调整副本数设置定时扩缩容规则8.2 存储优化对玩家数据启用压缩config set hash-max-ziplist-entries 512 config set hash-max-ziplist-value 64使用更高效的序列化协议将JSON改为MessagePack格式平均减少30%存储空间9. 扩展功能实现9.1 实时增量排行榜# 记录上次查看的排名 last_rank redis.zrevrank(leaderboard, uid) # 获取排名变化 current_rank redis.zrevrank(leaderboard, uid) delta last_rank - current_rank if last_rank else 09.2 分段统计功能# 统计各分数段人数 ranges [ (0, 1000), (1001, 2000), (2001, 3000) ] for min_s, max_s in ranges: count redis.zcount(leaderboard, min_s, max_s)10. 客户端优化技巧10.1 连接池配置pool ConnectionPool( max_connections100, socket_timeout5, health_check_interval30 )10.2 智能重试机制def safe_redis_command(): retries 3 while retries 0: try: return redis.command() except RedisError: retries - 1 time.sleep(1) raise Exception(Redis operation failed)在实际运行中这套方案已经稳定支撑了日均2亿次的排行榜查询请求。最大的收获是认识到看似简单的功能背后藏着无数需要权衡的技术细节。比如在一致性方面我们最终选择了最终一致性模型通过客户端缓存和合理的过期策略在性能和准确性之间找到了最佳平衡点。