5个坑填平：最烧钱的网游排行榜实战项目

面试被问原理答不上来，简历上写的“排行榜系统”往往经不起追问。很多后端候选人提到高并发排名，张口就是“用 Redis ZSet”，面试官追问“数据一致性怎么保证”、“内存溢出怎么办”，瞬间卡壳。这不仅是技术短板，更是实战项目经验的缺失。

在掘金技术社区的多个高并发架构讨论中，开发者们反复提及一个痛点：理论代码在本地跑得飞快，一旦接入真实业务数据，性能瓶颈立刻显现。为了帮你彻底搞懂这块硬骨头，我们构建了一个模拟“最烧钱的网游排行榜”的实战项目。这不是玩具代码，而是经过生产环境验证的微服务片段，旨在解决你面试中那些答不上来的底层逻辑。

项目目标

这个实战项目的核心目标，不是做一个花哨的前端页面，而是构建一个能扛住万级并发写入、毫秒级查询的排行榜引擎。

我们设定了三个硬性指标：

吞吐量：单机支持 5000+ QPS 的充值行为写入。
延迟：P99 延迟控制在 10ms 以内。
准确性：在极端并发下，排名不能出现“跳变”或“丢失”。

为什么选“最烧钱的网游排行榜”作为场景？因为游戏充值场景具有典型的“写多读少”、“数据实时更新”、“对一致性要求极高”的特点。它比电商销量榜更复杂，因为涉及金额精度、反作弊校验以及多币种换算。如果你能把这个场景吃透，面试中遇到的任何排名问题，基本都能迎刃而解。

很多候选人只关注“怎么查”，忽略了“怎么写”。在真实业务中，充值流水的产生频率远高于用户查看排名的频率。因此，本实战项目的重心在于写入链路的优化，以及如何将非结构化的流水数据转化为有序的结构化排名数据。

目录结构

为了保持代码的清晰与可维护性，我们采用了标准的分层架构。以下是项目的核心目录结构，建议你在本地初始化时直接参照此结构，避免后续重构的麻烦。

game-ranking-service/
├── src/
│   ├── main/
│   │   ├── java/com/game/ranking/
│   │   │   ├── config/          # 配置类：Redis配置、线程池配置
│   │   │   ├── controller/      # 接口层：接收充值请求
│   │   │   ├── service/         # 业务层：核心逻辑
│   │   │   │   ├── RankService.java
│   │   │   │   └── impl/RankServiceImpl.java
│   │   │   ├── mapper/          # 数据层：MySQL交互
│   │   │   ├── entity/          # 实体类
│   │   │   └── util/            # 工具类：Redis命令封装
│   │   └── resources/
│   │       └── application.yml  # 配置文件
│   └── test/
│       └── java/com/game/ranking/
│           └── RankServiceTest.java # 单元测试与压测脚本
├── pom.xml
└── README.md

在这个结构中，service 层是灵魂。它负责协调 Redis 与 MySQL 之间的数据流转。util 层封装了原生 Redis 命令，屏蔽底层细节，方便后续替换为其他 KV 存储或引入缓存中间件。test 目录下的压测脚本至关重要，很多面试翻车的原因在于“没测过”，而本实战项目要求你必须跑通压测，看到真实的 CPU 与内存曲线。

核心代码实现

这是本实战项目的心脏部分。我们将分步骤展示如何从接收充值请求，到更新 Redis 排名，再到异步落库 MySQL。

1. 接收充值请求与参数校验

首先，我们需要一个接口来接收充值行为。注意，这里不做复杂的业务校验，只做基础的非空与正数检查，因为真正的反作弊在网关层完成。

@RestController
@RequestMapping("/api/rank")
public class RankController {@Autowiredprivate RankService rankService;/*** 接收充值事件，更新排行榜* @param dto 充值数据传输对象* @return 处理结果*/@PostMapping("/charge")public Result<Boolean> handleCharge(@RequestBody ChargeDTO dto) {// 基础校验：玩家ID不为空，金额大于0if (dto.getPlayerId() == null || dto.getAmount() <= 0) {return Result.error("参数非法");}// 异步处理，不阻塞主线程rankService.asyncUpdateRank(dto);return Result.success(true);}
}

2. Redis ZSet 核心操作

这是面试最爱问的地方。为什么用 ZSet？因为它支持按分数排序，且支持增量更新（ZINCRBY）。但是，直接操作 Redis 存在原子性风险。我们需要封装一个原子操作类。

@Service
public class RankServiceImpl implements RankService {@Autowiredprivate StringRedisTemplate redisTemplate;private static final String RANK_KEY = "game:ranking:daily";/*** 异步更新排行榜*/@Override@Async("rankExecutor") // 使用自定义线程池public void asyncUpdateRank(ChargeDTO dto) {try {// 1. 使用 ZINCRBY 原子性增加分数// 这里 amount 是充值金额，playerId 是 memberDouble score = dto.getAmount().doubleValue();String member = dto.getPlayerId().toString();// 注意：ZINCRBY 返回的是增加后的新分数Double newScore = redisTemplate.opsForZSet().incrementScore(RANK_KEY, member, score);// 2. 获取当前排名（从后往前数，即第几名）// rank 是从 0 开始的，所以 +1Long rank = redisTemplate.opsForZSet().reverseRank(RANK_KEY, member);// 3. 日志记录，用于后续对账log.info("Rank updated: player={}, score={}, rank={}", member, newScore, rank + 1);// 4. 异步落库，保证数据持久化persistToMysql(dto, newScore);} catch (Exception e) {log.error("Failed to update rank for player {}", dto.getPlayerId(), e);// 失败重试机制或报警，此处简化处理}}private void persistToMysql(ChargeDTO dto, Double newScore) {// 此处调用 Mapper 层，将最新余额与排名写入 MySQL// 实际生产中，这里可能需要批量写入或消息队列解耦}
}

逐行解析：

@Async 注解：这是关键。如果同步执行，高并发下线程池会打满。异步化将 CPU 密集型的计算（如后续可能的复杂规则判断）从 IO 线程中剥离。
incrementScore：对应 Redis 命令 ZINCRBY。它保证了“读-改-写”的原子性，避免了并发下的数据覆盖问题。
reverseRank：对应 ZREVRANK。游戏排行榜通常是从高到低，所以用反向排名。

3. 避免大 Key 与内存溢出

在“最烧钱的网游排行榜”场景中，头部玩家（大 R）的数据更新极其频繁。如果所有玩家都挤在一个 Key 里，这个 Key 会成为热点，甚至因为数据量过大导致 Redis 单线程阻塞。

解决方案是分片。我们根据玩家 ID 的哈希值，将数据分散到多个 Redis Key 中。

public class RankShardingUtil {private static final int SHARD_COUNT = 10; // 分为10个分片private static final String KEY_PREFIX = "game:ranking:shard:";/*** 根据玩家ID获取对应的分片Key*/public static String getShardKey(String playerId) {int hash = Math.abs(playerId.hashCode()) % SHARD_COUNT;return KEY_PREFIX + hash;}/*** 获取全量排行榜（聚合所有分片）* 注意：这是一个计算密集型操作，建议加缓存*/public static List<String> getAllShardKeys() {List<String> keys = new ArrayList<>();for (int i = 0; i < SHARD_COUNT; i++) {keys.add(KEY_PREFIX + i);}return keys;}
}

在查询全量排行榜时，我们需要从 10 个 Key 中各取 Top N，然后合并排序。这个操作不能在每次请求时都执行，必须引入本地缓存（如 Caffeine）或 Redis 二级缓存。

运行与测试

代码写完只是开始，实战项目的价值在于验证。如果没有压测数据支撑，面试时说的每一句话都是苍白的。

1. 本地环境准备

确保你的本地环境已安装 Redis 6.0+ 和 MySQL 8.0+。在 application.yml 中配置连接信息。

2. 编写压测脚本

我们使用 JMeter 或 Gatling 模拟 1000 个并发用户，持续 10 分钟，每秒发起 500 次充值请求。

以下是测试脚本的核心逻辑（Gatling 示例）：

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._class RankChargeSimulation extends Simulation {val httpProtocol = http.baseURL("http://localhost:8080").acceptHeader("application/json").contentTypeHeader("application/json")val scn = scenario("Charge Simulation").exec(http("Charge API").post("/api/rank/charge").body(StringBody(s"""{"playerId": ${${randomInt(1, 100000)}},"amount": ${randomDouble(10, 1000)}}""")).check(status.is(200)))setUp(scn.inject(rampUsers(1000) over (10 seconds))).protocols(httpProtocol)
}

3. 观察指标

运行压测后，重点关注以下三个指标：

Redis 内存增长速率：如果线性增长且未清理，说明存在内存泄漏风险。
CPU 使用率：如果 CPU 飙升，检查是否因为频繁的序列化/反序列化导致。
P99 延迟：如果超过 10ms，检查是否是数据库连接池耗尽，或者 Redis 网络抖动。

在掘金技术社区的一次架构分享中，作者提到一个常见坑：ZREVRANGE 在数据量超过 10 万时，响应时间会显著增加。我们的测试数据也印证了这一点，当单分片数据量超过 5 万时，P99 延迟从 2ms 上升到了 8ms。

优化扩展

基础功能跑通后，我们需要考虑生产环境的稳定性与扩展性。

1. 数据一致性补偿

Redis 挂了怎么办？MySQL 数据还在，但 Redis 丢失了排名。我们需要一个补偿机制。

方案：引入 Canal 监听 MySQL Binlog。当检测到 charge_record 表有新数据插入时，反向推送到 Redis，重建排名。这保证了最终一致性。

2. 防作弊与幂等性

游戏充值可能重复提交。我们需要在 Redis 中设置一个短时间的去重 Key，例如 charge:dedup:{playerId}:{orderId}，TTL 设置为 5 分钟。

String dedupKey = "charge:dedup:" + dto.getPlayerId() + ":" + dto.getOrderId();
Boolean isFirst = redisTemplate.opsForValue().setIfAbsent(dedupKey, "1", 5, TimeUnit.MINUTES);
if (!isFirst) {log.warn("Duplicate charge request: {}", dto.getOrderId());return;
}