咱们hen多Zuo开发的朋友，脑子里一蹦出“排行榜”这三个字，下意识的反应就是——这还不简单？数据库里来个 ORDER BY 不就完事了？

确实Ru果你只是Zuo一个几千人的内部小游戏，或者一个日活几百的Demo，MySQL绝对Neng让你爽到飞起。但是兄弟们，咱们今天聊的是《王者荣耀》，是动辄亿级用户在线、每秒成千上万次查询的国民级应用。在这种体量下Ru果你还敢直接用 select * from user_info order by step desc 这种SQL去硬抗，那数据库分分钟教你Zuo人。

这可不是危言耸听。传统的关系型数据库会彻底崩盘。原因就一句话：磁盘扛不住排序算不动，并发撑不起。

一、 为什么MySQL在亿级排行面前“抬不起头”？

咱们来打个比方。比如微信运动的步数排行，或者我们要查询王者荣耀巅峰赛的前一百积分的玩家。这本质上就是一个经典的 TOP N 问题。

当数据量少的时候，MySQL的B+树索引确实Neng帮上忙。但一旦数据量突破千万、甚至上亿，情况就完全变了。你要知道，磁盘IO和内存操作的速度差了几个数量级。每一次查询，Ru果涉及到大量的磁盘寻道和读取，响应时间就会从毫秒级飙升到秒级，甚至直接超时。

geng别提，当全服玩家dou在疯狂地刷新榜单，试图kankan自己排第几的时候，数据库的CPU资源会被瞬间耗尽。这时候，别说查排行榜了就连登录功Neng可Nengdou会被拖垮。

二、 Redis：排行榜的“救世主”

既然磁盘不行，那咱们就上内存。Redis，就是这个领域的“超级英雄”。

Redis 提供了一种极其强大的数据结构，叫Zuo zset。这玩意儿就像是一个自带排序功Neng的魔法盒子。它类似于集合，但每个成员dou关联着一个分数。Redis 内部会根据这个分数，自动帮我们把成员排好队。

这就好比把一仓库货物分装到10辆卡车，每辆车只运1/10的货，装卸速度自然快10倍！Redis 用内存操作+单线程+IO多路复用这三把利剑，轻松切开高并发大山。

据有关测试证明，单机Redis可扛10万+ QPS，分片集群轻松突破百万级并发。这种性Neng，对于排行榜这种读多写少的场景来说简直是降维打击。

为什么 Redis 这么快？

咱们Ke以把 Redis 想象成那种超高效快餐窗口

1. 全内存操作数据dou在内存里不用去转那个慢吞吞的硬盘。 p>2. 核心操作秒回ZREVRANGE 这种命令，直接在内存结构里跳表取数据，快得惊人。 p>3. 单线程模型没有上下文切换的开销，一心一意只为处理请求。

三、 当“亿级”遇上“单Key”：新的噩梦来了

好，现在我们知道了要用 Redis 的 ZSET。hen多小伙伴一拍大腿，这就去写代码了：建一个 Key 叫 leaderboard，把全服几亿用户的分数全塞进去。

然后线上环境就炸了。

为什么？因为热点Key问题。

全服玩家频繁查询 ZREVRANGE leaderboard 0 99，导致所有请求集中访问同一个Key。这就像几亿人dou要通过同一扇门进出，这扇门的CPU和带宽瞬间被打满。

假设数据分片不均匀，极端情况下这个Redis实例直接崩溃，全服排行榜瘫痪。这可不是开玩笑的。

此外还有一个隐患：直接使用 ZREVRANGE 获取 Top N 时若数据量过大，虽然复杂度是 O + M)，但在某些特定操作或者数据结构调整时可Neng会引发性Neng抖动。geng别提，存储1亿用户，若每个键占32字节，仅键就需约3.2GB，加上分数和指针，内存压力巨大。

还有一个让人头疼的问题：持久化。Redis 的数据全放内存，RDB/AOF持久化时fork子进程引发内存翻倍。亿级数据的内存占用本来就高，这一翻倍，机器直接OOM。

四、 终极架构：分片存储与读写分离

那怎么办？难道 Redis 也不行了吗？当然不是。咱们得换个思路，不Neng把鸡蛋放在一个篮子里。

1. 怎么拆？—— 分片策略

既然一个 Key 存不下那就拆成多个 Key。我们Ke以按照这种思路：按分数区间拆分。

操作：将排行榜按分数区间拆分成多个Key，例如：rank:2500_2600，rank:2400_2500 等等。

咱们来kan一段伪代码逻辑，这可是解决问题的关键：

# 伪代码：2503分该放哪个区间？
if 2500 <= new_score <2600:
    扔进 rank:2500_2600
elif 2400 <= new_score <2500:
    扔进 rank:2400_2500
# 以此类推...

这样一来原本集中在一个 Key 上的巨大流量，就被分散到了几十个甚至上百个 Key 上。Redis 集群通过分片存储将数据拆分到多个实例，如同把1亿用户分配到10个小数据库，每个只需处理1000万数据，轻松实现负载均衡。

突然出现的高分用户可Neng打乱原有分片规则，导致数据集中在某个分片引发热点。但在这种按分数分片的策略下高分用户虽然少，但他们的 Key是独立的，不会影响到低分段玩家的查询体验。

2. 怎么拼？—— 查询逻辑

你可Neng会问：“拆开了我怎么查全服 Top 100？”

这就涉及到“怎么拼”的问题了。查询逻辑：查 Top 100 时只需访问 leaderboard:top1。

等等，这听起来好像又回到了原点？其实不然。我们Ke以维护一个较小的“全服前N名”的缓存 Key，或者通过聚合各个高分段 Key 的数据来得出。因为 Top 100 的玩家通常dou集中在Zui高的几个分数段，我们只需要去查 rank:3000_3100rank:2900_3000 这几个 Key，然后合并排序即可。这比去查一个包含1亿人的大 Key 要快得多得多。

3. 怎么动？—— 读写分离

为了进一步压榨性Neng，我们还Ke以引入读写分离。

主库处理写请求。多个从库轮询处理读请求。

毕竟排行榜这种功Neng，读的频率远远高于写的频率。把读请求分散到多个从库上，主库就Neng专心致志地处理积分geng新，系统的整体吞吐量直接翻倍。

五、 数据安全：别让 Redis 宕机毁了你的职业生涯

Redis 虽然快，但它有个让人心里发毛的缺点：数据可Neng丢失。

Redis 宕机可Neng导致Zui新数据丢失。对于排行榜来说丢个几分几秒的数据可Neng还Neng接受，但Ru果涉及到积分兑换奖励，那就是生产事故了。

所以我们必须要有容灾方案。

1. 异步双写

geng新分数时同步写入 Kafka，由消费者异步落库 MySQL，用于故障恢复。

这就像是给 Redis 买了一份“保险”。所有的积分变geng，不仅记在 Redis 里还会发一条消息给 Kafka。后台服务慢慢把这条消息消费掉，存进 MySQL。万一 Redis 真的挂了我们还Neng从 MySQL 里把数据重新加载回来。

2. 混合持久化

开启 RDB + AOF，平衡恢复速度与数据完整性。

RDB 恢复快，但可Neng会丢数据；AOF 数据安全性高，但恢复慢，文件体积大。混合持久化就是取长补短，把两者结合起来用。

六、 避坑指南：那些年我们踩过的雷

架构设计从来dou不是一蹴而就的，里面充满了各种细节的坑。

比如用户积分跨分片迁移时若未原子操作可Neng导致数据丢失或重复。

想象一下一个玩家本来在 2400 分段，突然一把连胜冲到了 2600 分段。这时候，我们需要把他从 rank:2400_2500 移除，加到 rank:2500_2600。Ru果这两步操作不是原子的，就会出现数据不一致。

这个实现没有问题的，Ru果表的数据量少的话，反而推荐这样实现。Ru果数据量多呢。则存在问题，尤其还涉及亿级的数据量时~ 这时候，你可Neng需要引入 Lua 脚本来保证 Redis 操作的原子性，或者使用分布式锁。

七、 ：Redis vs MySQL 的终极对决

Zui后咱们来个简单的对比，kankan两者的差距到底有多大。

以下为 Redis vs MySQL 性Neng对比：

MySQL磁盘IO密集，随着数据量增加，查询时间呈指数级上升。高并发下容易锁库、死锁，基本无法满足实时性要求。

Redis 内存计算，时间复杂度低，QPS 极高。配合分片集群，Ke以轻松应对亿级数据的存储和查询。

不仅仅是 redis 的 zset 支持排序，API 简单易用，还因为 redis 的排序快、可 性强、Neng轻松应对高并发。

所以当你下次再面对“如何架构亿级排行榜”这个问题时别再只盯着 ORDER BY 了。想想 Redis，想想分片，想想读写分离。这才是资深架构师该有的思考方式。

希望这篇文章Neng给你带来一点启发，Ru果你在项目中遇到了类似的难题，不妨试试这套组合拳，说不定会有意想不到的惊喜哦！

---