3个坑点讲透淘金币源码，搞定高频面试题
3个坑点讲透淘金币源码，搞定高频面试题
看了一堆教程还是不会写项目？别慌，这通常是把“业务逻辑”和“底层实现”割裂了。在掘金技术社区翻遍关于积分系统的讨论，你会发现大多数后端在面试中被问懵，不是因为不懂算法，而是没摸透像淘金币这种高并发场景下的核心源码。今天咱们不背八股文，直接拆解淘金币兑换模块的底层逻辑，把几个高频面试题的考点揉进源码里，让你下次遇到类似问题，能直接掏出设计思路应对。
入口定位：从用户点击到服务层的链路
很多人写项目时，习惯直接调数据库，这在低并发下没问题，但一旦放到淘金币这种量级，系统瞬间就崩了。我们得先看入口。在典型的电商中台架构中，用户点击“使用淘金币”按钮后，请求并不会直接落在业务库上，而是经过网关层鉴权，再进入具体的业务服务。
这里有一个容易被忽视的细节：幂等性控制。在源码入口处，通常会先通过 Redis 做一层拦截。为什么？因为网络抖动可能导致用户连续点击，如果每次都生成订单，后续对账就是个灾难。
// 伪代码：淘金币兑换入口拦截器
public class CoinExchangeInterceptor implements HandlerInterceptor {@Autowiredprivate StringRedisTemplate redisTemplate;@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {// 1. 获取用户ID和订单唯一标识（通常由前端生成或网关生成）String userId = (String) request.getAttribute(userId);String orderId = request.getParameter(orderId);// 2. 构建Redis Key，利用setnx保证原子性String key = coin:lock: + userId + : + orderId;// 3. 尝试加锁，超时时间设为30秒，防止死锁Boolean isLock = redisTemplate.opsForValue().setIfAbsent(key, 1, 30, TimeUnit.SECONDS);if (!isLock) {// 4. 如果加锁失败，说明是重复请求，直接返回throw new BusinessException(请勿重复提交);}return true;}
}这段代码看似简单，却是解决高频面试题中“如何防止重复支付”的关键。很多初学者会忽略 TimeUnit 的设置，导致一旦程序异常退出，锁永远不释放，直接造成线上事故。
核心片段：事务一致性与余额扣减
进入业务核心，最头疼的就是“扣金币”和“发权益”这两件事如何保证一致性。如果扣了金币但权益没发出去，用户会投诉；如果权益发了但金币没扣，平台就亏了。
在淘金币的源码实现中，并没有简单地使用数据库事务包裹整个流程，因为发权益可能涉及外部服务（如物流、优惠券中心），网络延迟不可控。这里采用了一种最终一致性的方案。
// 伪代码：淘金币扣减核心逻辑
@Service
public class CoinService {@Autowiredprivate CoinMapper coinMapper;@Autowiredprivate MessageTemplate messageTemplate;@Transactional(rollbackFor = Exception.class)public void deductCoin(String userId, Integer amount, String orderId) {// 1. 乐观锁更新余额// 注意：WHERE 条件中包含了 version 字段，防止并发覆盖int rows = coinMapper.updateBalance(userId, amount, userId + : + orderId);if (rows == 0) {// 2. 更新失败，可能是余额不足或版本冲突，抛出异常回滚throw new BusinessException(扣减失败，请刷新重试);}// 3. 事务提交前，发送延迟消息// 这里利用 RocketMQ 的定时消息特性，设置延迟 10 秒Message msg = new Message(coin_topic, deduct_success, orderId, userId + amount);messageTemplate.sendDelay(msg, 10);}
}这里有两个高频面试题的考点：乐观锁 vs 悲观锁：源码中使用了 version 字段，这是典型的乐观锁策略。在高并发读多写少的场景下，乐观锁性能远优于 SELECT FOR UPDATE 的悲观锁。
事务边界与消息发送：注意，消息发送是在事务内部。如果事务回滚，消息也会丢失吗？这里其实有一个隐患，标准做法是使用本地消息表或者事务消息（Transaction Message）。上述代码是简化版，生产环境中，messageTemplate.sendDelay 应该被替换为 RocketMQ 的事务消息发送逻辑，确保“扣减成功”与“消息发出”的原子性。设计思想：为什么不用分布式锁？
很多开发者看到并发问题，第一反应是上 Redisson 分布式锁。但在淘金币这种秒杀级场景中，分布式锁的性能瓶颈非常明显。
源码的设计思想核心在于：把并发压力前置到缓存层，后端只做单条记录的原子更新。缓存层预减：在 Redis 中维护一个金币余额缓存，先执行 DECRBY。如果 Redis 返回负数，直接拒绝，根本不进数据库。
数据库兜底：只有 Redis 扣减成功的请求，才会进入数据库执行上述的乐观锁更新。
异步补偿：通过消息队列监听“扣减成功”事件，异步处理后续的权益发放、日志记录等非核心链路。这种架构将数据库的 QPS 压力降低了 90% 以上。在面试中，如果你能讲清楚“为什么选乐观锁而不是分布式锁”，以及“缓存与数据库不一致如何处理”，基本就能拿下这轮技术面。
手写简化版：本地模拟高并发场景
为了验证上述逻辑，我们可以写一个极简的本地模拟版本。假设我们有一个内存版的“Redis”和一个模拟的“数据库”。
// 伪代码：本地模拟高并发扣减
public class LocalCoinSimulator {// 模拟 Redis 缓存private static final ConcurrentHashMapString, Integer redisCache = new ConcurrentHashMap();// 模拟数据库private static final ConcurrentHashMapString, Integer dbBalance = new ConcurrentHashMap();public static void main(String[] args) {// 初始化：用户 1001，余额 100redisCache.put(1001, 100);dbBalance.put(1001, 100);// 模拟 1000 个并发请求，每个请求扣 1 个金币ExecutorService executor = Executors.newFixedThreadPool(20);CountDownLatch latch = new CountDownLatch(1000);for (int i = 0; i 1000; i++) {executor.submit(() - {try {exchangeCoin(1001, 1);} catch (Exception e) {// 忽略异常} finally {latch.countDown();}});}latch.await();System.out.println(Redis: + redisCache.get(1001));System.out.println(DB: + dbBalance.get(1001));}public static void exchangeCoin(String userId, int amount) {// 1. 原子扣减 Redis (模拟 Lua 脚本保证原子性)Integer result = redisCache.computeIfPresent(userId, (k, v) - {if (v = amount) {return v - amount;} else {// 余额不足，抛异常throw new RuntimeException(Insufficient balance);}});// 2. 只有 Redis 成功，才操作 DB// 这里简化为直接更新，实际应使用乐观锁dbBalance.computeIfPresent(userId, (k, v) - v - amount);}
}运行这段代码，你会发现 Redis 和 DB 的最终状态是一致的（都是 0，因为 1000 个请求只够扣 100 个，剩下的会抛异常）。但在真实场景中，第 2 步的 DB 操作如果失败，就需要依靠对账系统来修复 Redis 与 DB 的差异。这就是“最终一致性”的代价。
应用场景与面试避坑指南
理解了淘金币的源码逻辑，我们可以将其迁移到很多实际项目中：电商优惠券核销：逻辑与金币扣减几乎一致，区别在于优惠券有有效期和库存限制，需要在 Redis 中额外维护库存计数。
游戏道具购买：高并发下，道具的发放可能涉及多个服务（背包、邮件、特效），必须使用消息队列解耦。
银行转账：这是强一致性场景，不能用上述的最终一致性方案，必须使用 TCC 或 Saga 模式。在准备高频面试题时，务必注意以下避坑点：不要盲目吹嘘分布式锁：面试官会追问“锁的粒度”、“锁过期怎么办”、“Redis 宕机了怎么办”。如果答不上来，不如老实说“在可控范围内，优先用乐观锁”。
强调对账机制：任何最终一致性方案，都必须提到“对账”。如果没有对账，就是耍流氓。
区分缓存穿透与击穿：在金币余额查询场景中，如果用户余额为 0，每次请求都会打到数据库，这就是穿透。解决方案是缓存空对象，设置较短的过期时间。淘金币的源码实现，本质上是CAP 定理在工程实践中的妥协。它牺牲了一致性（短暂不一致），换取了可用性（高并发不崩溃）和分区容错性（网络抖动可恢复）。
这个知识点你面试被问过吗？留言说说