3个致命陷阱：中国电信积分兑换商城源码避坑指南

面试被问到积分系统高并发下的数据一致性，你答不上来？别慌，这不只是面试尴尬，更是业务崩溃的前兆。中国电信积分兑换商城源码避坑指南，直接带你拆解官方源码仓库中的核心逻辑。很多应届生只盯着前端页面，却忽略了后端在积分扣减、库存校验上的深坑。今天这篇，不聊虚的，只讲代码里那些让你上线就翻车的细节。

入口定位：从Controller到Service的调用链

打开中国电信积分兑换商城的官方源码仓库，入口非常清晰。所有兑换请求都汇聚在 ExchangeController 中。别小看这个类，它是整个交易闭环的起点。

@RestController
@RequestMapping("/api/exchange")
public class ExchangeController {@Autowiredprivate ExchangeService exchangeService;// 用户发起积分兑换请求@PostMapping("/submit")public Result<ExchangeRecord> submitExchange(@RequestBody ExchangeRequest request) {// 1. 基础参数校验：防止恶意请求if (request.getItemId() == null || request.getPoints() <= 0) {throw new BusinessException("参数错误");}// 2. 幂等性检查：防止用户重复点击提交String idempotentKey = generateIdempotentKey(request.getUserId(), request.getItemId());if (redisTemplate.hasKey(idempotentKey)) {throw new BusinessException("请勿重复提交");}// 3. 调用核心业务逻辑ExchangeRecord record = exchangeService.doExchange(request);// 4. 设置幂等键，有效期5分钟redisTemplate.opsForValue().set(idempotentKey, "1", 5, TimeUnit.MINUTES);return Result.success(record);}
}

逐行解读：

@PostMapping("/submit")：映射兑换接口，所有兑换行为走这里。
generateIdempotentKey：这是第一道防线。很多应届生写的代码直接调Service，结果用户手抖点了两次，积分扣了两次，客诉电话打爆客服。这里用Redis做幂等控制，Key由用户ID+商品ID组成。
redisTemplate.hasKey：快速判断是否重复请求。注意，这里不是分布式锁，是状态标记。
TimeUnit.MINUTES：幂等键不能永久存在，否则用户5分钟内真想买同款都买不了。

很多人在这一步就栽了。他们以为幂等就是加个锁，其实幂等是“多次执行结果和一次执行结果相同”。这里用Redis标记“已处理”，比加锁更轻量，更适合高并发场景。

核心片段：积分扣减与库存校验的事务陷阱

进入 ExchangeService.doExchange，这里才是真正的雷区。积分和库存是两张表，分属不同服务，甚至不同数据库。

@Service
public class ExchangeService {@Autowiredprivate PointsService pointsService;@Autowiredprivate InventoryService inventoryService;@Autowiredprivate OrderService orderService;@Transactionalpublic ExchangeRecord doExchange(ExchangeRequest request) {// 1. 查询商品详情，获取所需积分和当前库存Product product = productService.getById(request.getItemId());if (product == null || product.getStatus() != 1) {throw new BusinessException("商品不存在或已下架");}// 2. 校验用户积分是否充足int userPoints = pointsService.getPointsByUserId(request.getUserId());if (userPoints < product.getCostPoints()) {throw new BusinessException("积分不足");}// 3. 【关键坑点】先扣库存，再扣积分// 使用乐观锁更新库存，防止超卖boolean inventoryUpdated = inventoryService.decreaseInventory(product.getId(), 1, product.getVersion());if (!inventoryUpdated) {throw new BusinessException("库存不足");}// 4. 扣减用户积分boolean pointsDeducted = pointsService.deductPoints(request.getUserId(), product.getCostPoints());if (!pointsDeducted) {// 回滚库存inventoryService.increaseInventory(product.getId(), 1);throw new BusinessException("积分扣减失败");}// 5. 创建兑换订单ExchangeRecord record = orderService.createOrder(request, product);return record;}
}

逐行解读与设计思想：

@Transactional：这里的事务边界非常危险。积分服务和库存服务如果是微架构，本地事务根本无法覆盖两个数据源。但在单体架构或同库分表场景下，这个注解是生效的。官方源码仓库在这里采用了“最终一致性”思路，而非强一致性。
decreaseInventory：注意第三个参数 product.getVersion()。这是乐观锁的核心。SQL语句类似 UPDATE inventory SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ?。如果version不匹配，更新0行，返回false，说明有并发冲突。
先扣库存，再扣积分：这是经过权衡的设计。如果先扣积分再扣库存，一旦库存不足，积分扣了还要回滚，积分回滚失败会导致用户资产损失，这是重大事故。先扣库存，库存不足直接返回，积分未动，用户无感知。
手动回滚库存：如果积分扣减失败（比如积分服务超时），必须手动调用 increaseInventory 回滚。这里没有用try-catch-finally自动回滚，是因为 @Transactional 在异常时会回滚，但这里的 inventoryUpdated 是业务逻辑成功，不是数据库异常。如果积分扣减抛异常，事务回滚，库存自动回滚；如果积分扣减返回false，必须手动回滚。这种混合模式极易出错。

避坑指南：

陷阱1：事务范围过大。把查询商品也放进事务里，长时间占用数据库连接。
陷阱2：忽略乐观锁版本。直接 stock = stock - 1，高并发下必然超卖。
陷阱3：回滚逻辑缺失。积分扣减失败时，库存没回滚，导致库存永久丢失。

手写简化版：用Redis+Lua实现原子性扣减

为了更彻底地避免分布式事务的复杂性，很多资深工程师会引入Redis+Lua脚本，将积分扣减和库存校验合并为原子操作。

-- Redis Lua脚本：原子性扣减积分和库存
local userId = KEYS[1]
local productId = KEYS[2]
local costPoints = tonumber(ARGV[1])
local stock = tonumber(ARGV[2])-- 1. 获取用户当前积分
local userPoints = tonumber(redis.call('get', 'points:' .. userId))
if userPoints == nil thenreturn -1 -- 用户不存在
end-- 2. 检查积分是否充足
if userPoints < costPoints thenreturn -2 -- 积分不足
end-- 3. 检查库存是否充足
local currentStock = tonumber(redis.call('get', 'stock:' .. productId))
if currentStock == nil or currentStock < 1 thenreturn -3 -- 库存不足
end-- 4. 原子性执行扣减
redis.call('decrby', 'points:' .. userId, costPoints)
redis.call('decrby', 'stock:' .. productId, 1)return 1 -- 成功

// Java调用Lua脚本
public boolean atomicExchange(String userId, String productId, int costPoints) {List<String> keys = Arrays.asList("points:" + userId, "stock:" + productId);List<String> args = Arrays.asList(String.valueOf(costPoints), "1");// 执行Lua脚本，保证原子性Object result = redisTemplate.execute(new DefaultRedisScript<>(luaScript, Object.class),keys,args);if (result == null) {return false;}int code = (Integer) result;switch (code) {case 1:return true; // 成功case -2:throw new BusinessException("积分不足");case -3:throw new BusinessException("库存不足");default:return false;}
}

设计思想：

原子性：Lua脚本在Redis中是原子执行的，不存在中间状态。积分和库存要么都扣，要么都不扣。
性能：Redis内存操作，QPS可达十万级，远超数据库。
一致性：这里牺牲了强一致性，换取了高性能。积分和库存的最终一致性通过异步对账任务保证。

避坑指南：

陷阱1：Redis数据丢失。如果Redis宕机，积分和库存数据丢失。必须配合RDB+AOF持久化，并设置合理的刷盘策略。
陷阱2：Key设计不合理。points:{userId} 和 stock:{productId} 必须使用相同的Redis集群，否则Lua脚本无法跨节点执行。
陷阱3：异步对账缺失。Redis扣减成功后，必须异步通知数据库更新，否则数据库和Redis数据不一致。