之前在做红包类活动时遇到过一件让产品和开发都冒冷汗的事运营人员发起一个 200 元的红包活动活动结束后一算账实际发出去了 250 元。多出的 50 元不是预算问题也不是人为操作失误而是在并发领取场景下金额计算出现了重叠两个请求同时读到同一个余额各自扣减后又分别写回导致最终金额对不上。很多人第一反应是“并发问题加个锁就行”但真正去落地时才发现锁加在哪里、锁的粒度多大、Redis 和数据库怎么配合、消息重复消费怎么处理每一步都可能埋坑。本文就用“200 元红包发出 250 元”这个场景带大家拆解分布式系统中强一致性的本质以及如何落到代码层面解决这类问题。1. 问题复现从“200 变 250”说起1.1 业务场景描述假设我们有一个红包系统运营创建了一个总金额 200 元的红包活动用户可以同时参与领取。系统初始化时红包池余额为 200 元。每个用户领取时系统需要做两件事判断当前红包池余额是否足够。如果足够扣减红包池金额记录一条领取明细。这是非常典型的“余额扣减类”业务类似库存扣减、账户转账、优惠券核销。这类业务最核心的要求就是扣减前后的金额必须精确一致不能多扣更不能少扣。在单机环境下这个逻辑用数据库事务就能很好解决。但在分布式、高并发的场景下问题就变得复杂起来。1.2 事故是怎么发生的我们先写一个最直观的实现方式这也是很多新手容易写出的代码// 伪代码不加任何并发控制的领取逻辑 public void receiveRedPacket(Long activityId, Long userId) { // 1. 查询红包池余额 BigDecimal balance redPacketMapper.getBalance(activityId); // 2. 判断余额是否足够假设每次领取固定 50 元 if (balance.compareTo(BigDecimal.valueOf(50)) 0) { throw new BusinessException(红包已被领完); } // 3. 扣减余额 BigDecimal newBalance balance.subtract(BigDecimal.valueOf(50)); redPacketMapper.updateBalance(activityId, newBalance); // 4. 插入领取明细 receiveRecordMapper.insert(activityId, userId, BigDecimal.valueOf(50)); }这段代码在单线程下没有任何问题。但一旦并发量上来两个请求同时执行到第 1 步读到的余额都是 200 元。请求 A 判断 200 大于 50执行扣减余额变为 150请求 B 手里拿的还是 200也判断通过执行扣减余额同样变为 150。两次扣减各 50 元总共应该扣 100 元但最终余额只减少了 50 元。如果初始 200 元被 4 个并发请求同时读到最极端的情况下每个人都认为余额足够最终红包池余额可能变成负数或者出现“发出 250 元、账上只扣了 200 元”的结果。这就是标题里“200 元红包发出 250 元”的技术根源——读写下文没有做原子性保护多个请求基于同一个旧值进行计算造成数据相互覆盖。1.3 问题本质是什么这个问题从根上看可以拆成两层并发控制缺失多个线程或进程同时读写同一份数据没有互斥机制。事务边界过大或过小查询余额、计算新余额、更新余额、插入明细这四个动作没有被放进同一个原子操作里。在传统单体应用中我们依赖数据库的行锁和事务来解决在分布式系统中服务可能部署了多个实例数据库也可能做了分库分表这时候就不能只靠本地的 synchronized而要考虑跨进程的一致性方案。2. 一致性概念强一致性、弱一致性与最终一致性2.1 什么是强一致性强一致性Strong Consistency是指任何一次读操作都能读到某个数据的最近一次写操作的结果系统中的所有节点在同一时刻看到的数据是完全一致的。用朋友圈来类比你发了一条动态朋友圈的“强一致”意味着所有好友在刷新时必须立刻看到这条动态如果某个好友刷新后看不到就不满足强一致。在分布式系统中强一致性通常由 Paxos、Raft 等共识算法或者数据库的分布式事务如 XA 协议来保证。代价是可用性和性能会受到影响因为每次读写都要在多个节点之间同步确认。2.2 弱一致性与最终一致性与强一致性相对的是弱一致性。弱一致性不保证读操作能读到最新的写结果只保证在一段时间之后数据会达到一个一致的状态。最终一致性是弱一致性的一种特例系统不保证任何时刻数据都是一致的但保证在没有新写入的情况下经过一段时间的异步同步所有节点的数据最终会一致。典型例子是 DNS 解析。你修改了一个域名的解析记录全球的 DNS 服务器不会同时更新有的地区可能需要几分钟甚至更久才能生效但最终所有 DNS 服务器都会拿到新记录。2.3 红包场景需要什么级别的一致性回到红包场景余额扣减不能出现超发所以“扣减金额”这个写操作必须满足强一致。用户看到的领取结果、红包池剩余金额可以接受短暂的延迟这类读操作可以走最终一致。所以一个成熟的红包系统并不是全链路都做强一致而是对关键写路径做强一致对非关键读路径做最终一致。这也符合互联网架构中常见的设计理念能不强一致的地方尽量不强一致因为强一致的性能代价很高。3. 保证红包金额强一致的四种方案3.1 方案一数据库行锁 事务最简单利用数据库自身的行锁机制通过SELECT ... FOR UPDATE锁定红包池记录或者直接在 UPDATE 语句里加余额条件保证同一时间只有一个请求能修改余额。-- 方案 A使用行锁事务内部串行化操作 BEGIN; SELECT balance FROM red_packet WHERE activity_id ? FOR UPDATE; -- 业务判断 计算 -- 扣减余额 UPDATE red_packet SET balance balance - 50, version version 1 WHERE activity_id ?; INSERT INTO receive_record (activity_id, user_id, amount) VALUES (?, ?, 50); COMMIT;-- 方案 B乐观锁通过条件更新避免覆盖 UPDATE red_packet SET balance balance - 50 WHERE activity_id ? AND balance 50;方案 B 的巧妙之处在于它把“余额判断”和“扣减”合并成了一条原子 SQL。数据库在执行UPDATE时会对命中行加锁即使多个请求同时执行也只有第一个请求能成功匹配balance 50的条件后面的请求会因为条件不满足而更新 0 行通过Affected Rows是否为 1 来判断是否领取成功。这种方案是红包系统中最常见、最稳定、也最容易维护的做法适合大多数中小型项目。3.2 方案二Redis Lua 脚本高性能场景当红包活动的并发量非常高数据库行锁会成为瓶颈时可以先用 Redis 做前置的余额扣减Redis 单线程模型配合 Lua 脚本可以保证原子性。-- 文件路径red_packet_deduct.lua -- KEYS[1]: 红包池余额 key -- ARGV[1]: 扣减金额 local balance tonumber(redis.call(GET, KEYS[1]) or 0) local amount tonumber(ARGV[1]) if balance amount then return -1 end redis.call(DECRBY, KEYS[1], amount) return balance - amountJava 端调用Autowired private StringRedisTemplate stringRedisTemplate; public boolean tryDeductRedPacket(String activityId, BigDecimal amount) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setLocation(new ClassPathResource(red_packet_deduct.lua)); script.setResultType(Long.class); ListString keys Collections.singletonList(red:packet:balance: activityId); Long result stringRedisTemplate.execute(script, keys, amount.toPlainString()); return result ! null result 0; }要注意Redis 方案只是解决了“高并发下的扣减原子性”最终的数据落库还是需要异步同步。如果 Redis 和数据库的一致性没有做好仍然可能出现数据库余额和 Redis 余额不一致的问题。所以该方案通常配合对账任务一起使用保证最终一致。3.3 方案三分布式锁跨实例互斥如果服务是多实例部署且数据库压力可控可以用分布式锁将同一红包活动的领取操作串行化。// 使用 Redis SETNX 实现分布式锁 public boolean tryLock(String lockKey, String requestId, long expireTime) { return stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, expireTime, TimeUnit.SECONDS); }获取锁成功后执行原有逻辑最后释放锁。这个方案的重点是锁的粒度要小应该按activityId加锁而不是全局加锁。如果全局只用一个锁会导致不同红包活动之间互相影响系统的吞吐量大大下降。另外分布式锁要特别注意误删锁和锁过期的问题。误删锁可以用 value 存请求唯一标识释放时先比对再删除锁过期需要结合业务超时时间设置避免业务还没执行完锁就释放了其他请求趁虚而入。3.4 方案四事务消息 幂等异步最终一致在某些红包场景里扣减和发放并不需要实时同步完成。例如用户点击领取后先返回“领取中”后台异步处理扣减和入账。这时可以引入事务消息通过消息队列保证扣减操作至少成功投递一次消费者端通过幂等保证重复消息不会重复扣减。这个方案的难点在于幂等设计。通常的做法是在业务表上建立唯一索引用user_id activity_id batch_no作为幂等键重复消息插入时触发唯一索引冲突直接忽略。// 消费端幂等处理 Transactional public void handleReceiveMessage(ReceiveMessage msg) { try { receiveRecordMapper.insert(msg.getActivityId(), msg.getUserId(), msg.getAmount(), msg.getBatchNo()); } catch (DuplicateKeyException e) { // 已经处理过直接返回 log.warn(重复消费消息batchNo{}, msg.getBatchNo()); } }四种方案对比方案一致性强度性能实现复杂度适用场景数据库行锁 事务强一致一般低中小项目架构简单乐观锁条件更新强一致中等极低大多数业务场景推荐优先考虑Redis Lua 脚本强一致Redis 内高中高并发热点需要异步落库与对账分布式锁强一致锁内串行中低中多实例跨进程互斥事务消息 幂等最终一致高较高异步链路容忍短暂不一致4. 完整实战红包系统金额强一致代码实现下面我们完整实现一个基于“乐观锁 数据库事务”的红包领取流程。这个方案兼顾了实现简洁和业务可靠适合大多数场景。4.1 项目结构与表设计项目使用 Spring Boot MyBatis-Plus MySQL基础结构如下red-packet-demo ├── pom.xml └── src/main/java/com/example/redpacket ├── RedPacketApplication.java ├── controller/RedPacketController.java ├── service/RedPacketService.java ├── mapper/RedPacketMapper.java ├── mapper/ReceiveRecordMapper.java └── entity/ ├── RedPacket.java └── ReceiveRecord.java数据库表-- 红包池表 CREATE TABLE red_packet ( id bigint(20) NOT NULL AUTO_INCREMENT, activity_id varchar(64) NOT NULL COMMENT 活动ID, total_amount decimal(10,2) NOT NULL COMMENT 总金额, balance decimal(10,2) NOT NULL COMMENT 剩余金额, version int(11) NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1-可用 0-停用, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_activity_id (activity_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 领取明细表 CREATE TABLE receive_record ( id bigint(20) NOT NULL AUTO_INCREMENT, activity_id varchar(64) NOT NULL, user_id varchar(64) NOT NULL, amount decimal(10,2) NOT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_activity_user (activity_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;表的设计有两个关键点red_packet表用version字段作为乐观锁的依据。receive_record表用uk_activity_user唯一索引保证一个用户在同一活动中只能领取一次这本身就是一层幂等保护。4.2 核心更新 SQL乐观锁的关键在更新语句上!-- 文件路径src/main/resources/mapper/RedPacketMapper.xml -- update iddeductBalance UPDATE red_packet SET balance balance - #{amount}, version version 1, update_time NOW() WHERE activity_id #{activityId} AND balance #{amount} AND status 1 /update这条 SQL 的巧妙之处在于两点balance balance - #{amount}是原子操作数据库在更新这行时会对这行记录加行锁。WHERE balance #{amount}直接在校验阶段拦截余额不足的情况。即使两个请求同时执行数据库也会让它们串行更新。第一个请求更新成功余额从 200 变为 100第二个请求执行时balance 50依然成立继续扣减。直到余额不足时更新影响行数为 0。如果你需要严格的乐观锁版本控制可以基于version来写update iddeductBalanceByVersion UPDATE red_packet SET balance balance - #{amount}, version version 1, update_time NOW() WHERE activity_id #{activityId} AND version #{version} AND balance #{amount} AND status 1 /update对应的 Mapper 接口// 文件路径src/main/java/com/example/redpacket/mapper/RedPacketMapper.java public interface RedPacketMapper extends BaseMapperRedPacket { int deductBalance(Param(activityId) String activityId, Param(amount) BigDecimal amount); int deductBalanceByVersion(Param(activityId) String activityId, Param(amount) BigDecimal amount, Param(version) Integer version); }4.3 领取服务实现// 文件路径src/main/java/com/example/redpacket/service/RedPacketService.java Service Slf4j public class RedPacketService { Resource private RedPacketMapper redPacketMapper; Resource private ReceiveRecordMapper receiveRecordMapper; Transactional(rollbackFor Exception.class) public boolean receive(String activityId, String userId, BigDecimal amount) { // 1. 插入领取明细唯一索引兜底幂等 try { ReceiveRecord record new ReceiveRecord(); record.setActivityId(activityId); record.setUserId(userId); record.setAmount(amount); record.setCreateTime(new Date()); receiveRecordMapper.insert(record); } catch (DuplicateKeyException e) { // 同一个用户重复领取直接返回失败 log.warn(用户重复领取: activityId{}, userId{}, activityId, userId); return false; } // 2. 乐观锁扣减余额 int rows redPacketMapper.deductBalance(activityId, amount); if (rows 0) { // 余客不足抛出异常触发事务回滚 throw new BusinessException(红包已被领完); } // 3. 其他业务逻辑如发送消息通知等 log.info(领取成功: activityId{}, userId{}, amount{}, activityId, userId, amount); return true; } }这里有一个非常容易被忽略的细节先插入明细再做余额扣减。为什么要这样安排因为明细表的唯一索引是幂等兜底。如果先扣减余额、再插入明细在插入明细失败时事务回滚余额扣减也会回滚看起来问题不大。但如果在高并发下同一用户同时发起多个请求两个请求都进入扣减流程都扣减成功了然后插入明细时只有一个成功另一个插入触发唯一索引冲突抛异常——由于事务回滚这个请求的余额扣减也会回滚看起来也没有问题。真正要紧的是另一个细节Transactional只能保证方法内部所有数据库操作在同一个事务里。如果这个服务在将来被拆分或者有人把receiveRecordMapper.insert改成异步 RPC 调用那么事务的保护边界就被打破了。这时候就要考虑分布式事务的解决方案而不是继续依赖本地事务。4.4 防止异常情况吞掉事务回滚注意上面代码中我们捕获了DuplicateKeyException并打印日志这本身没问题。但有一种常见的坑是调用方在外层没有设置事务传播行为或者BusinessException没有被 Spring 的事务管理器识别。默认情况下Spring 只对RuntimeException和Error触发回滚对受检异常不生效。BusinessException建议继承RuntimeException否则你需要在Transactional上显式指定rollbackFor Exception.class。public class BusinessException extends RuntimeException { public BusinessException(String message) { super(message); } }4.5 控制层示例// 文件路径src/main/java/com/example/redpacket/controller/RedPacketController.java RestController RequestMapping(/red-packet) public class RedPacketController { Resource private RedPacketService redPacketService; PostMapping(/receive) public ResultBoolean receive(RequestParam String activityId, RequestParam String userId, RequestParam BigDecimal amount) { try { boolean success redPacketService.receive(activityId, userId, amount); return Result.success(success); } catch (BusinessException e) { return Result.fail(e.getMessage()); } } }4.6 模拟并发验证为了验证方案是否真的能防止超发可以写一个简单的并发测试// 文件路径src/test/java/com/example/redpacket/RedPacketConcurrencyTest.java SpringBootTest public class RedPacketConcurrencyTest { Resource private RedPacketService redPacketService; Test public void testConcurrentReceive() throws InterruptedException { String activityId ACT20250101; // 模拟 20 个用户并发领取每个用户 50 元 int userCount 20; CountDownLatch latch new CountDownLatch(userCount); ExecutorService executor Executors.newFixedThreadPool(20); AtomicInteger successCount new AtomicInteger(0); for (int i 0; i userCount; i) { String userId user_ i; executor.submit(() - { try { boolean success redPacketService.receive(activityId, userId, BigDecimal.valueOf(50)); if (success) { successCount.incrementAndGet(); } } catch (Exception e) { // 预期中的余额不足异常 } finally { latch.countDown(); } }); } latch.await(); executor.shutdown(); // 查询最终余额 BigDecimal balance redPacketMapper.getBalanceByActivityId(activityId); System.out.println(成功领取次数 successCount.get()); System.out.println(剩余金额 balance); // 初始 200 元每份 50 元最多 4 人成功 assert successCount.get() 4; assert balance.compareTo(BigDecimal.ZERO) 0; } }预期结果是20 个并发请求中只有 4 个能领到红包剩余金额为 0不会出现余额为负数的情况。5. 常见问题与排查思路5.1 问题列表问题现象常见原因解决思路红包金额出现负余额扣减逻辑基于旧值计算并发覆盖使用乐观锁条件更新将判断和扣减合并为原子 SQL同一用户重复领取成功缺少幂等控制明细表加唯一索引插入时捕获重复键异常使用分布式锁后吞吐量极低锁粒度设置过大按activityId加锁不要使用全局锁Redis 扣减了余额但数据库没扣Redis 与数据库异步同步缺失或失败增加对账任务按日核对 Redis 和数据库余额事务回滚不生效BusinessException是受检异常或事务边界不对继承RuntimeException或指定rollbackFor高并发下数据库连接打满每个请求持有事务时间过长优化事务内逻辑非必要操作移出事务引入 Redis 前置扣减5.2 排查清单如果你在项目中遇到红包金额不一致的问题可以按以下顺序排查检查更新 SQL 是否原子有没有出现“查询余额 → Java 计算新余额 → 更新余额”这种三步逻辑如果有改成balance balance - #{amount}这种原子表达式。检查唯一索引用户维度是否具备天然幂等检查事务边界整个“插入明细 扣减余额”是否在同一个事务里事务是否真的生效检查多实例部署如果服务有多个实例synchronized是无效的需要分布式锁或数据库乐观锁。检查对账Redis 余额和数据库余额是否定期核对5.3 一个容易被忽略的坑affected rows的误判在使用UPDATE ... WHERE balance amount时有些人喜欢根据“更新行数”来判断成功但如果余额恰好等于扣减金额且前后值相同MySQL 默认配置下affected rows可能返回 0会被误判为失败。解决方法是使用version字段或者将 SQL 改成始终变更版本号UPDATE red_packet SET balance balance - #{amount}, version version 1 WHERE activity_id #{activityId} AND balance #{amount}由于version总是 1这一行始终发生了变化affected rows的返回值就是可靠的。这是一个生产环境中非常值得注意的细节。6. 最佳实践与工程建议6.1 优先使用数据库乐观锁而不是盲目上分布式锁很多团队一提到并发问题就想到 Redis 分布式锁但实际上数据库乐观锁在多数场景下更简单、更可靠不需要额外维护锁的过期时间。不需要处理锁的误删问题。事务回滚时锁自动释放。性能在大多数业务量级下完全够用。分布式锁只有在多实例、跨服务、或者需要串行化一段复杂逻辑时才有必要。6.2 幂等设计是底线不管是乐观锁、分布式锁还是消息队列方案幂等都应该是一道独立的安全网。具体到红包系统唯一索引activity_id user_id。业务流水号每次领取生成唯一的batch_no。状态机记录订单或领取流水状态重复请求只允许流转一次。只要幂等做对了即使前置的并发控制失效最坏情况也只是浪费一次查询而不是造成资金损失。6.3 对账是分布式系统的最后防线再完善的技术方案也无法 100% 保证系统不出问题。硬件故障、网络超时、消息丢失、人为误操作每一样都可能打破一致性。所以生产环境中必须建设对账机制每日定时任务统计红包活动应发总额、实发总额、剩余金额三者的关系必须满足恒等式。明细与总额核对领取明细的金额总和是否等于实际扣减的总金额。异常告警任何对不上账的情况第一时间短信或电话告警而不是第二天看报表才发现。6.4 配置管理与变更规范红包活动的金额、预算、参与者白名单等参数线上环境要经过完整的配置变更流程。推荐通过 Apollo 等配置中心管理并遵循以下原则配置修改前先申请变更后在测试环境验证。生产变更选择低峰期并设置配置灰度发布。每个配置项都要有修改记录便于回溯。6.5 金额计算使用 BigDecimal禁止使用浮点型在涉及金额的代码中使用float或double是大忌。浮点数的二进制表示会产生精度误差累加多次后误差会被放大。所有金额字段在 Java 中使用BigDecimal在数据库中使用DECIMAL(10, 2)。// 错误示例禁止使用 double balance 200.0; balance - 50.0; // 正确示例 BigDecimal balance new BigDecimal(200.00); BigDecimal amount new BigDecimal(50.00); BigDecimal result balance.subtract(amount);注意BigDecimal构造时尽量使用字符串入参不要用new BigDecimal(0.1)这种浮点入参否则同样会有精度问题。7. 总结与后续学习方向“200 元红包发出 250 元”看似是一个搞笑的标题背后却是分布式系统中非常经典的一致性难题。本文从问题复现开始解释了强一致性和最终一致性的区别给出了数据库行锁、乐观锁、Redis Lua 脚本、分布式锁、事务消息等多种解决方案并基于乐观锁完成了完整的红包领取代码示例。如果你发现自己项目中依然存在金额不一致的问题优先检查三件事扣减 SQL 是不是原子的明细表有没有唯一索引事务回滚规则是否正确把这三点做好就能避免 90% 以上的并发资金事故。如果还想继续深入建议按以下顺序学习CAP 定理与 BASE 理论理解分布式系统一致性的理论基础。分布式事务的 XA、TCC、Saga 模式对比不同方案的优缺点。Redis 与数据库双写一致性方案包括缓存更新策略和 binlog 订阅。消息队列的幂等消费与事务消息原理。本文示例完整代码可以在本地直接运行建议用并发测试用例验证一下超发场景只有亲眼看到乐观锁拦截了多余请求才能对“强一致性”有更深刻的感知。