小伙伴去字节面试，结果一面就挂了...就因为一道题没答好。
面试官就问了一个看似很简单的问题：
“如果让你来设计一个类似微信运动的步数排行榜，系统要支持上亿用户，还要能实时查看好友间的排名，你会怎么做？”
小伙伴第一反应就是：“用 MySQL，建个步数字段，查询的时候 ORDER BY steps DESC 再分页不就行了？”然后...就没有然后了。
兄弟们，这道题看似人畜无害，其实是道“天坑”题！它把海量数据下的高并发写入、实时查询、存储扩展等经典难题全揉到了一起。直接说MySQL，等于一脚踩进了面试官的“死亡陷阱”。
今天，我就把这道题的“满分答案”给你掰扯清楚。下次再遇到，直接按我说的这“三板斧”打出去，保证让面试官对你刮目相看！
为什么这题能干掉一半的候选人？
在亮出答案前，你得先明白它到底难在哪。它有四大“天王级”挑战：
1、写入地狱
上亿用户在饭后、睡前集中上报步数，写入请求量瞬间爆炸，你管这叫“写入洪峰”？这简直是“写入海啸”！
2、查询噩梦
好友排行榜要求秒级刷新。用MySQL对亿级大表做ORDER BY？数据库分分钟被干瘫痪，等着 DBA 提刀来见你吧。
3、存储黑洞
亿级用户，每人每天一条记录，一个月就是30亿条！如果用MySQL，你的磁盘和钱包👛都将不堪重负。
4、关系迷宫
每个人的好友列表都不同，你根本没法提前算好一个“通用”的排行榜。查询时，必须先捞出好友关系，这又增加了一层复杂性。
第一板斧：写入流程 -> “异步解耦，削峰填谷”
想扛住写入海啸，硬碰硬是死路一条。我们必须“以柔克刚”。
我们的核心思路是——让消息队列（MQ）做“蓄水池”。
1、用户上报步数
请求到达我们的 Java 业务服务。
2、当个“甩手掌柜”
业务服务接到请求后，不进行任何计算！不写入任何数据库！ 它的唯一使命，就是把 {userId, steps, timestamp} 格式的消息，飞快地塞进 Kafka 或 RocketMQ 中，然后立刻告诉 App：“好了，我收到啦！”
3、消费服务慢悠悠处理
下游的消费服务，可以按照自己的节奏，从容地从 MQ 中拉取消息进行处理。
4、亮出王牌：Redis ZSET
消费服务拿到数据后，执行最关键的一步：
# 将用户A的步数更新到今天的排行榜ZADD
leaderboard:2025-09-12 15000 user_id_A
ZADD 命令简直是为排行榜而生的神器！它会自动覆盖旧的步数，并且时间复杂度只有 O(logN)，性能炸裂！
小结：通过 MQ 这个“蓄水池”，我们把瞬时的写入海啸，变成了平缓的小溪。前端接口响应飞快，后端服务稳定可靠，完美！
第二板斧：查询流程 -> “动静分离，内存计算”
搞定了写入，查询怎么做才能秒开？核心思想是“动静分离”。
- “静”的是关系
用户和好友的关系，变化频率低，是相对静态的数据。
- “动”的是步数
步数实时变化，是动态数据。
我们将这两部分数据分开处理：
1、查“户口本”
当用户 A 来查询时，我们先去 MySQL 分库分表 中，像查户口本一样，拉取他所有的好友ID列表。这一步走的是持久化存储，因为关系数据必须可靠。
2、查“记分牌”
拿到好友ID列表后（比如200个），千万别傻乎乎地循环查 200 次 Redis！ 而是应该使用 Pipeline 或多线程并发，一次性把所有好友的步数（Score）从 Redis 这个“实时记分牌”中批量取出来。
3、内存里“比武”
现在，我们拿到了一个几十、几百人的小名单和他们各自的步数。在服务的内存里对这个小列表进行一次排序，速度快到飞起！
4、组装信息，返回！
最后，把排序好的列表，配上用户的昵称、头像（这些可以有另一层缓存），一起返回给前端。
小结：把慢查询（查关系）和快查询（查分数）分开，最后在内存中做轻量计算。整套流程下来，用户感觉就是“嗖”的一下，排行榜就出来了！
第三板斧：顶住追问 -> “展现你架构的完整性”
搞定上面两步，你已经超越了 80% 的候选人。但想拿到 Offer，还得顶住面试官可能接下来的“夺命连环问”。
追问1：“如果有几百万好友的大V怎么办？实时查不是要卡死？”
答：问得好！这就是典型的“热点用户”问题。对这类用户，我们会采用“预计算 + 缓存”的策略。
正如上图中的“对比方案”，我们会有一个后台定时任务（例如每分钟执行一次），为这些大V提前算好他们的好友排行榜，然后把整个排好序的列表结果，直接缓存到一个单独的 Redis Key 里。当大V来查询时，我们直接返回这个“成品”，不走实时计算，体验同样丝滑。
追问2：“Redis 要是挂了，今天的数据不就全丢了？”
答：我们有“双重保险”来保证万无一失。
1、高可用
Redis 会部署成主从 + 哨兵模式。主节点挂了，从节点秒级顶上，服务不会中断。
2、数据可恢复
就算整个 Redis 集群都坏了，也别慌！回头看我们的整体架构，上游的 MQ 中还保留着最近几天的全量步数消息。我们可以立刻启动一个恢复程序，从 MQ 中回放当天的数据，分分钟就能重建一个一模一样的排行榜！这就保证了数据的最终一致性。
总结一下
面对这种亿级系统设计题，记住这套组合拳：
1、异步解耦
用 MQ 扛住写入流量。
2、冷热分离
用 Redis (热) 存实时数据，用 MySQL (冷) 存关系数据。
3、动静分离
查询时，组合来自不同存储介质的数据，在内存中做最终计算。
4、考虑兜底
对热点问题和高可用问题，有成熟的降级和恢复预案。
这套拳打下来，思路清晰，细节拉满，面试官不给你过，都说不过去！
作者丨Fox
来源丨公众号：Fox爱分享（ID：dcl_yc）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
