3行代码拆解英雄联盟礼包领取，面试必问核心逻辑 官方文档太长抓不住重点？别慌。很多开发者一看到“英雄联盟礼包领取”这种业务场景，就以为只是调个API发个券，结果面试时被问倒：高并发下如何保证礼包不超发？幂等性怎么实现？分布式锁选Redis还是数据库？这些才是面试必问的硬核考点。 今天不聊虚的，直接拆解一个高并发礼包领取系统的核心源码。我们假设这是一个真实的业务场景：某电竞赛事活动，用户点击“领取”按钮，后端需要校验资格、扣减库存、记录流水。看似简单，实则坑多。如果你只盯着业务逻辑，忽略了底层的并发控制与状态机设计，上线必挂。 入口定位：从HTTP请求到服务层 很多新手容易犯的一个错误，是把所有逻辑都塞进Controller层。这在单体架构初期或许还能凑合，但一旦流量上来，代码维护性极差。在微服务架构下，标准的分层设计是：Controller - Service - DAO/Cache。 让我们看一个典型的入口代码。这里我们采用Spring Boot风格，但核心逻辑适用于任何语言。注意看，Controller层只做参数校验和路由，真正的业务逻辑下沉到Service层。 @RestController @RequestMapping(/api/gift) public class GiftController {@Autowiredprivate GiftService giftService;/*** 领取礼包接口* @param request 领取请求，包含用户ID和礼包ID* @return 领取结果*/@PostMapping(/receive)public ResultString receiveGift(@RequestBody ReceiveRequest request) {// 1. 参数非空校验，快速失败if (request.getUserId() == null || request.getGiftId() == null) {return Result.error(参数错误);}// 2. 调用业务层处理核心逻辑// 注意：这里不直接返回库存数量，而是返回领取状态// 避免在Controller层处理复杂的异常捕获return giftService.processReceive(request);} }这段代码看似平淡，实则体现了防御式编程的思想。在高性能场景下，参数校验必须在入口完成，避免无效请求穿透到数据库层，消耗宝贵的连接池资源。很多团队在压测时发现数据库连接池耗尽，根源往往不在SQL写得不好，而在于入口层没有挡住非法请求。 核心片段：高并发下的库存扣减 这是整个系统的心脏。如何保证在10万QPS下，库存从100减到0，且不出现负数？ 最直观的想法是使用UPDATE语句：UPDATE gift SET stock = stock - 1 WHERE id = 1 AND stock 0。这在低并发下没问题，但在高并发下，数据库行锁竞争会导致吞吐量急剧下降。更糟糕的是，如果事务超时，可能出现死锁。 业界标准方案是：Redis预扣减 + 数据库最终一致性。 我们来看核心Service层的实现，这里使用了Redisson分布式锁（或者更高效的Lua脚本原子操作）。为了讲解清晰，我们采用Lua脚本方式，它比加锁性能更高，因为Lua脚本在Redis中是原子执行的，无需客户端显式加锁。 -- Lua脚本：原子性扣减库存 -- KEYS[1]: 礼包库存Key, e.g., gift:stock:1001 -- KEYS[2]: 用户领取记录Key, e.g., gift:received:1001 -- ARGV[1]: 用户ID -- ARGV[2]: 扣减数量 (通常为1)local stock = tonumber(redis.call('GET', KEYS[1]))-- 1. 检查库存是否存在 if stock == nil thenreturn -1 -- 库存Key不存在，可能是初始化失败 end-- 2. 检查用户是否已领取 (幂等性校验) -- 使用Set结构存储已领取用户ID，O(1)复杂度 local isReceived = redis.call('SISMEMBER', KEYS[2], ARGV[1]) if isReceived == 1 thenreturn -2 -- 用户已领取，拒绝重复请求 end-- 3. 检查库存是否充足 if stock = 0 thenreturn -3 -- 库存不足 end-- 4. 执行扣减 redis.call('DECR', KEYS[1])-- 5. 记录用户领取状态 redis.call('SADD', KEYS[2], ARGV[1])return 1 -- 领取成功这段Lua脚本是解决超卖问题的关键。让我们逐行拆解其设计思想：GET获取库存：注意，我们是在同一个原子操作中读取和判断。如果在Java代码中先GET再DECR，两个请求可能在GET之后、DECR之前插入，导致超卖。 SISMEMBER幂等校验：这是面试高频考点。为什么用Set？因为Set的SADD和SISMEMBER操作都是O(1)的，且天然去重。如果用List或String，判断是否已领取需要遍历或解析，性能差且易出错。 DECR原子扣减：Redis的DECR命令是原子性的，保证了扣减过程的线程安全。 返回码设计：返回-1, -2, -3等不同状态码，让Java层能精确区分错误原因（库存未初始化、已领取、库存不足），便于前端给出精准提示。关键点：为什么不在Java里做if (stock 0)判断？因为Lua脚本在Redis服务端执行，全程无网络往返，避免了竞态条件。这是客户端逻辑与服务器端原子操作的经典对比。 设计思想：为什么选择这种架构？ 这里涉及两个核心设计原则：最终一致性 和 幂等性。 1. 为什么是“Redis预扣减”而不是直接数据库？ 数据库的行锁粒度太粗。一个UPDATE语句会锁住整行，甚至索引页。在秒杀场景下，成千上万个请求排队等待行锁释放，数据库CPU飙升，TPS却上不去。而Redis是单线程模型，所有命令串行执行，天然无锁，吞吐量可达10万+ QPS。 2. 如何保证数据最终一致？ Redis扣减成功，不代表数据库一定更新成功。如果Redis扣减后，服务宕机，或者数据库写入失败，就会出现“用户以为领到了，但后台没记录”的情况。 解决方案是消息队列（MQ）异步落库。 @Service public class GiftService {@Autowiredprivate RedisTemplateString, String redisTemplate;@Autowiredprivate RabbitTemplate rabbitTemplate;private DefaultRedisScriptLong luaScript;@PostConstructpublic void init() {// 加载Lua脚本到Redis服务端，避免每次传输脚本字符串luaScript = new DefaultRedisScript();luaScript.setScriptText(this.getClass().getResourceAsStream(/lua/gift_receive.lua));luaScript.setResultType(Long.class);}public ResultString processReceive(ReceiveRequest request) {String stockKey = gift:stock: + request.getGiftId();String userKey = gift:received: + request.getGiftId();// 执行Lua脚本Long result = redisTemplate.execute(luaScript, Arrays.asList(stockKey, userKey), request.getUserId(), 1);if (result == 1) {// 扣减成功，发送MQ消息，异步写入数据库// 这里不能直接写库，否则高并发下DB会成为瓶颈rabbitTemplate.convertAndSend(gift.exchange, gift.receive, request);return Result.success(领取成功);} else if (result == -2) {return Result.error(您已领取过该礼包);} else if (result == -3) {return Result.error(手慢了，礼包已抢光);} else {return Result.error(系统繁忙，请稍后重试);}} }注意@PostConstruct中的脚本加载。很多新手每次执行都传Lua脚本字符串，这会导致每次请求都涉及网络传输脚本内容，性能浪费严重。Redis支持EVALSHA，通过脚本的SHA1值执行，只需首次上传脚本，后续直接执行，效率提升显著。 3. 幂等性的深层理解 幂等性（Idempotency）是分布式系统的基石。同一个请求，无论执行多少次，结果应该相同。在上述设计中，SISMEMBER + SADD保证了用户只能领取一次。 但面试中常追问：如果MQ消息重复投递怎么办？ 答：数据库层必须做幂等。在gift_record表中，建立唯一索引UNIQUE(user_id, gift_id)。当消费者收到重复消息时，插入操作会抛出DuplicateKeyException，捕获该异常并忽略即可。这是数据库约束作为最后防线的经典实践。 手写简化版：从零实现一个迷你领取器 为了加深理解，我们手写一个不依赖Spring的简化版，使用Jedis和纯Java逻辑，剥离框架干扰，看清本质。 import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; import redis.clients.jedis.params.SetParams; import java.util.Arrays; import java.util.UUID;public class MiniGiftReceiver {private JedisPool jedisPool;public MiniGiftReceiver(String host, int port) {jedisPool = new JedisPool(host, port);}public boolean receive(String giftId, String userId) {try (Jedis jedis = jedisPool.getResource()) {String stockKey = gift:stock: + giftId;String lockKey = gift:lock: + giftId + : + userId;String requestId = UUID.randomUUID().toString(); // 幂等Key// 1. 尝试获取分布式锁 (防止同一用户并发点击)// 使用SETNX + EXPIRE，防止死锁String result = jedis.set(lockKey, requestId, SetParams.setParams().nx().ex(5));if (!OK.equals(result)) {// 获取锁失败，说明该用户正在处理中，直接返回false// 或者可以返回“处理中”，视业务需求而定return false; }try {// 2. 执行Lua脚本 (同上，省略Lua加载细节，假设已缓存)Long status = (Long) jedis.eval(LUA_SCRIPT, Arrays.asList(stockKey, gift:received: + giftId), Arrays.asList(userId, 1));if (status == 1) {// 3. 扣减成功，这里模拟发送MQ// 实际项目中应替换为MQ客户端调用System.out.println(User + userId + received gift + giftId);return true;} else {return false;}} finally {// 4. 释放锁// 注意：必须使用Lua脚本删除锁，确保删除的是自己加的锁// 防止锁过期后被其他线程获取，此时本线程再删除会导致误删String unlockScript = if redis.call('get', KEYS[1]) == ARGV[1] then +return redis.call('del', KEYS[1]) +else return 0 end;jedis.eval(unlockScript, Arrays.asList(lockKey), Arrays.asList(requestId));}} catch (Exception e) {e.printStackTrace();return false;}}private static final String LUA_SCRIPT = local stock = tonumber(redis.call('GET', KEYS[1])) +if stock == nil then return -1 end +if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then return -2 end +if stock = 0 then return -3 end +redis.call('DECR', KEYS[1]) +redis.call('SADD', KEYS[2], ARGV[1]) +return 1; }这段代码展示了分布式锁的正确释放方式。很多开发者直接用DEL lockKey，这在锁过期后是灾难性的。必须使用requestId作为锁的值，并在删除前比对，确保只删除自己持有的锁。这是Redisson等框架内部实现的原理。 应用场景与避坑指南 这套架构不仅适用于游戏礼包，还广泛应用于电商秒杀、优惠券发放、热点数据限流等场景。 避坑点1：Redis持久化策略 如果Redis重启，库存数据丢失怎么办？ 答：礼包库存属于易失性数据。活动开始前，由定时任务从数据库加载初始库存到Redis。如果Redis宕机，活动暂停或从数据库重新加载。不要试图用RDB/AOF保证库存的强一致性，那会牺牲性能。 避坑点2：热点Key问题 如果某个礼包极热，所有请求都打到同一个Redis Key上，单线程的Redis可能成为瓶颈。 对策：库存分桶。将一个礼包的库存拆分为N个桶，例如gift:stock:1001:0 到 gift:stock:1001:9。用户请求时，根据userId % 10路由到不同的桶。这样，压力分散到10个Key上，Redis的吞吐量提升10倍。 避坑点3：监控与降级 必须监控Redis的hit_rate（命中率）和avg_latency（平均延迟）。当延迟超过阈值，立即触发降级策略：关闭领取入口，返回“活动火爆，请稍后”。保护核心服务永远比满足所有请求更重要。 这个知识点你面试被问过吗？留言说说