面试官就问了一个看似很简单的问题：

“如果让你来设计一个类似微信运动的步数排行榜，系统要支持上亿用户，还要能实时查看好友间的排名，你会怎么做？”

小伙伴第一反应就是：“用 MySQL，建个步数字段，查询的时候 ORDER BY steps DESC 再分页不就行了？”然后...就没有然后了。

兄弟们，这道题看似人畜无害，其实是道“天坑”题！它把海量数据下的高并发写入、实时查询、存储扩展等经典难题全揉到了一起。直接说MySQL，等于一脚踩进了面试官的“死亡陷阱”。

今天，我就把这道题的“满分答案”给你掰扯清楚。下次再遇到，直接按我说的这“三板斧”打出去，保证让面试官对你刮目相看！

在亮出答案前，你得先明白它到底难在哪。它有四大“天王级”挑战：

上亿用户在饭后、睡前集中上报步数，写入请求量瞬间爆炸，你管这叫“写入洪峰”？这简直是“写入海啸”！

好友排行榜要求秒级刷新。用MySQL对亿级大表做ORDER BY？数据库分分钟被干瘫痪，等着 DBA 提刀来见你吧。

亿级用户，每人每天一条记录，一个月就是30亿条！如果用MySQL，你的磁盘和钱包都将不堪重负。

每个人的好友列表都不同，你根本没法提前算好一个“通用”的排行榜。查询时，必须先捞出好友关系，这又增加了一层复杂性。

想扛住写入海啸，硬碰硬是死路一条。我们必须“以柔克刚”。

我们的核心思路是——让消息队列（MQ）做“蓄水池”。

请求到达我们的 Java 业务服务。

业务服务接到请求后，不进行任何计算！不写入任何数据库！ 它的唯一使命，就是把 {userId, steps, timestamp} 格式的消息，飞快地塞进 Kafka 或 RocketMQ 中，然后立刻告诉 App：“好了，我收到啦！”

下游的消费服务，可以按照自己的节奏，从容地从 MQ 中拉取消息进行处理。

消费服务拿到数据后，执行最关键的一步： 

# 将用户A的步数更新到今天的排行榜ZADD leaderboard:2025-09-12 15000 user_id_A

ZADD 命令简直是为排行榜而生的神器！它会自动覆盖旧的步数，并且时间复杂度只有 O(logN)，性能炸裂！

搞定了写入，查询怎么做才能秒开？核心思想是“动静分离”。

用户和好友的关系，变化频率低，是相对静态的数据。

步数实时变化，是动态数据。

我们将这两部分数据分开处理：

当用户 A 来查询时，我们先去 MySQL 分库分表 中，像查户口本一样，拉取他所有的好友ID列表。这一步走的是持久化存储，因为关系数据必须可靠。

拿到好友ID列表后（比如200个），千万别傻乎乎地循环查 200 次 Redis！ 而是应该使用 Pipeline 或多线程并发，一次性把所有好友的步数（Score）从 Redis 这个“实时记分牌”中批量取出来。

现在，我们拿到了一个几十、几百人的小名单和他们各自的步数。在服务的内存里对这个小列表进行一次排序，速度快到飞起！

最后，把排序好的列表，配上用户的昵称、头像（这些可以有另一层缓存），一起返回给前端。

搞定上面两步，你已经超越了 80% 的候选人。但想拿到 Offer，还得顶住面试官可能接下来的“夺命连环问”。

答：问得好！这就是典型的“热点用户”问题。对这类用户，我们会采用“预计算 + 缓存”的策略。

正如上图中的“对比方案”，我们会有一个后台定时任务（例如每分钟执行一次），为这些大V提前算好他们的好友排行榜，然后把整个排好序的列表结果，直接缓存到一个单独的 Redis Key 里。当大V来查询时，我们直接返回这个“成品”，不走实时计算，体验同样丝滑。

答：我们有“双重保险”来保证万无一失。

1、高可用

Redis 会部署成主从 + 哨兵模式。主节点挂了，从节点秒级顶上，服务不会中断。

2、数据可恢复

就算整个 Redis 集群都坏了，也别慌！回头看我们的整体架构，上游的 MQ 中还保留着最近几天的全量步数消息。我们可以立刻启动一个恢复程序，从 MQ 中回放当天的数据，分分钟就能重建一个一模一样的排行榜！这就保证了数据的最终一致性。

面对这种亿级系统设计题，记住这套组合拳：

用 MQ 扛住写入流量。

用 Redis (热) 存实时数据，用 MySQL (冷) 存关系数据。

查询时，组合来自不同存储介质的数据，在内存中做最终计算。

对热点问题和高可用问题，有成熟的降级和恢复预案。

这套拳打下来，思路清晰，细节拉满，面试官不给你过，都说不过去！