3行代码拆解英雄联盟礼包领取，面试必问核心逻辑
官方文档太长抓不住重点？别慌。很多开发者一看到“英雄联盟礼包领取”这种业务场景，就以为只是调个API发个券，结果面试时被问倒：高并发下如何保证礼包不超发？幂等性怎么实现？分布式锁选Redis还是数据库？这些才是面试必问的硬核考点。
今天不聊虚的，直接拆解一个高并发礼包领取系统的核心源码。我们假设这是一个真实的业务场景：某电竞赛事活动，用户点击“领取”按钮，后端需要校验资格、扣减库存、记录流水。看似简单，实则坑多。如果你只盯着业务逻辑，忽略了底层的并发控制与状态机设计，上线必挂。
入口定位：从HTTP请求到服务层
很多新手容易犯的一个错误，是把所有逻辑都塞进Controller层。这在单体架构初期或许还能凑合，但一旦流量上来，代码维护性极差。在微服务架构下，标准的分层设计是：Controller - Service - DAO/Cache。
让我们看一个典型的入口代码。这里我们采用Spring Boot风格，但核心逻辑适用于任何语言。注意看，Controller层只做参数校验和路由，真正的业务逻辑下沉到Service层。
@RestController
@RequestMapping(/api/gift)
public class GiftController {
@Autowired
private 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 then
return -1 -- 库存Key不存在，可能是初始化失败
end
-- 2. 检查用户是否已领取 (幂等性校验)
-- 使用Set结构存储已领取用户ID，O(1)复杂度
local isReceived = redis.call('SISMEMBER', KEYS[2], ARGV[1])
if isReceived == 1 then
return -2 -- 用户已领取，拒绝重复请求
end
-- 3. 检查库存是否充足
if stock = 0 then
return -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 {
@Autowired
private RedisTemplateString, String redisTemplate;
@Autowired
private RabbitTemplate rabbitTemplate;
private DefaultRedisScriptLong luaScript;
@PostConstruct
public 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（平均延迟）。当延迟超过阈值，立即触发降级策略：关闭领取入口，返回“活动火爆，请稍后”。保护核心服务永远比满足所有请求更重要。
这个知识点你面试被问过吗？留言说说 
长河君 · 2026/9/22 18:10:20 · 阅读 1.2k 3行代码拆解英雄联盟礼包领取，面试必问核心逻辑
3行代码拆解英雄联盟礼包领取，面试必问核心逻辑
官方文档太长抓不住重点？别慌。很多开发者一看到“英雄联盟礼包领取”这种业务场景，就以为只是调个API发个券，结果面试时被问倒：高并发下如何保证礼包不超发？幂等性怎么实现？分布式锁选Redis还是数据库？这些才是面试必问的硬核考点。
今天不聊虚的，直接拆解一个高并发礼包领取系统的核心源码。我们假设这是一个真实的业务场景：某电竞赛事活动，用户点击“领取”按钮，后端需要校验资格、扣减库存、记录流水。看似简单，实则坑多。如果你只盯着业务逻辑，忽略了底层的并发控制与状态机设计，上线必挂。
入口定位：从HTTP请求到服务层
很多新手容易犯的一个错误，是把所有逻辑都塞进Controller层。这在单体架构初期或许还能凑合，但一旦流量上来，代码维护性极差。在微服务架构下，标准的分层设计是：Controller - Service - DAO/Cache。
让我们看一个典型的入口代码。这里我们采用Spring Boot风格，但核心逻辑适用于任何语言。注意看，Controller层只做参数校验和路由，真正的业务逻辑下沉到Service层。
@RestController
@RequestMapping(/api/gift)
public class GiftController {
@Autowired
private 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 then
return -1 -- 库存Key不存在，可能是初始化失败
end
-- 2. 检查用户是否已领取 (幂等性校验)
-- 使用Set结构存储已领取用户ID，O(1)复杂度
local isReceived = redis.call('SISMEMBER', KEYS[2], ARGV[1])
if isReceived == 1 then
return -2 -- 用户已领取，拒绝重复请求
end
-- 3. 检查库存是否充足
if stock = 0 then
return -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 {
@Autowired
private RedisTemplateString, String redisTemplate;
@Autowired
private RabbitTemplate rabbitTemplate;
private DefaultRedisScriptLong luaScript;
@PostConstruct
public 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（平均延迟）。当延迟超过阈值，立即触发降级策略：关闭领取入口，返回“活动火爆，请稍后”。保护核心服务永远比满足所有请求更重要。
这个知识点你面试被问过吗？留言说说