高并发下怎么做余额扣减这个问题我至少被问过十次面试问、项目评审问、系统故障复盘也问。很多人第一反应是“用事务啊两条update搞定”听起来没错但一旦压到5000 QPS你会立刻发现数据库的InnoDB行锁变成一把巨大的串行闸门账扣不准、超扣、死锁、接口超时全来了。今天这篇文章我结合自己实操过的扣减系统从数据库方案到Redis缓存扣减再串到Sentinel流量治理把高并发余额扣减这条链路掰开揉碎希望给正在做账户、钱包、积分系统的你一些真正能落地的参考。写这篇内容之前我大概梳理了一下会讲到四个关键词幂等、无锁化、最终一致性、限流削峰。你把这四个词理解透了不管是用数据库锁还是引入中间件心里都有数。这篇文章适合正在做订单支付、钱包转账、库存扣减、积分消耗这类强一致事务场景的开发者也适合想搞明白Sentinel在真实扣减场景里怎么用的后端同学。1. 余额扣减为什么难先看清三个隐藏敌人1.1 你以为的扣减只是“减法”实际是“共享资源的并发写”余额扣减本质上是一个共享账户的写操作。比如你账户里有100元几十个请求同时要扣如果并发没控制好最终余额可能变成负数或者出现“超扣”现象。很多人第一直觉是加一个synchronized或者Lock锁但这只解决单机问题一旦服务部署多副本JVM锁瞬间失效。再往后想到数据库select for update又会出现另一个问题行锁竞争。我见过一个比较典型的场景秒杀活动中同一个热销账户比如平台补贴账户被所有用户共享扣减结果数据库那一行的行锁等待直接打满了连接池。数据库的CPU不高事务提交时间也不长但请求就是全部堆积在“锁等待”上。这种问题不是SQL优化能解决的而是锁粒度太粗。1.2 隐藏敌人一事务重试造成的重复扣高并发下接口可能会超时客户端会重试。如果你只是写了一个update account set balance balance - amount where id ?重试两次就扣两次。很多人说“重试请求我们通过唯一请求号判断”但判断去重的代码和扣减代码不在同一个事务里依然会有漏洞。一旦去重表和账户表不在同一个本地事务里就会出现扣了钱但标记没写入下一次重试照样扣成功。这个问题的本质是扣减动作必须幂等。也就是同一个请求无论执行多少次效果跟只执行一次一样。别以为简单做起来需要考虑的东西很多后面第3章我会细说。1.3 隐藏敌人二并发扣减导致超扣数据库都不报错看这个经典案例-- 伪代码先查询余额再判断是否够扣最后执行扣减 SELECT balance FROM account WHERE id 100; -- 结果50 if (balance 20) { // 判断通过准备扣20 UPDATE account SET balance balance - 20 WHERE id 100; }如果不是原子操作两个请求同时查到余额都是50同时判断可以扣20然后都执行update最终余额是10而不是30不会其实是30算一下两个20都成功50-20-2010那原本只剩下10却放了两个20出去就是超扣了10元。这还只是两并发高并发下会更夸张。要完全解决超扣必须把“余额判断”和“余额扣减”合成一个原子操作数据库里最直接的方式是UPDATE ... WHERE balance amount让数据库帮你做条件判断用行锁的原子性把检查和扣减合二为一。1.4 隐藏敌人三数据库行锁成为性能瓶颈即便你把超扣问题解决了只用一个update语句保持原子性高并发下的行锁依然可怕。假设单行数据的update执行耗时1ms那同一行理论上每秒最多只能串行执行1000次。一旦瞬时并发达到5000其余4000个请求都要排队等锁超过数据库innodb_lock_wait_timeout默认的50秒直接报Lock wait timeout exceeded。这就是余额扣减难的核心矛盾既要保证同一行并发扣减的强一致又要尽量减轻行锁对吞吐量的影响。怎么破靠单一数据库方案很难必须分层流量入口先削峰数据库层用条件更新兜底中间再加一层缓存扣减扛峰值。2. 数据库层的正统做法条件更新加流水事务2.1 保证原子性把判断和扣减写进同一条SQL常规账务系统里最稳的扣减SQL长这样UPDATE account SET balance balance - #{amount}, update_time NOW() WHERE id #{accountId} AND balance #{amount} AND status 1;balance #{amount}这个条件非常关键。它让数据库在行锁内部完成“余额够不够”的校验不够的话影响行数为0你再根据影响行数判断是否失败。如果影响行数为0说明余额不足或者账户异常返回业务失败影响行数为1说明扣减成功。这里需要注意的一点如果你用了MyBatis-Plus这类工具别拿实体类先selectById再setBalance再updateById那个流程没法保证原子性。怼着Mapper写一条带条件的update才是正确姿势。2.2 流水表扣减不能只改余额必须留痕只改余额出了问题没法追溯。正儿八经的扣减应该跟着一条流水记录比如-- 账户流水表 CREATE TABLE account_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_id BIGINT NOT NULL, request_id VARCHAR(64) NOT NULL, amount DECIMAL(12,2) NOT NULL, flow_type TINYINT NOT NULL COMMENT 1-扣减 2-充值 3-冻结 4-解冻, before_balance DECIMAL(12,2) NOT NULL, after_balance DECIMAL(12,2) NOT NULL, create_time DATETIME NOT NULL, UNIQUE KEY uk_request_id(request_id) ) ENGINEInnoDB;request_id唯一约束这步是幂等的关键。每次扣减请求带一个全局唯一的请求ID流水表插入时如果违反唯一约束说明这个请求已经处理过直接返回上次的结果。余额更新和流水插入必须在同一个数据库事务里保证“余额变了但流水没记”这类问题不发生。这也是本地事务方案最常见的姿势Transactional(rollbackFor Exception.class) public void deduct(Long accountId, BigDecimal amount, String requestId) { // 1. 幂等检查查流水表是否已存在 request_id // 2. 条件更新余额 int count accountMapper.deductBalance(accountId, amount); if (count 0) { throw new InsufficientBalanceException(余额不足); } // 3. 插入流水 accountFlowMapper.insert(accountId, requestId, amount); }2.3 为什么“先查后扣”容易踩坑实际项目怎么改我接手过一个老系统代码里就是先select ... for update锁行再判余额再update。当时压测一上500并发就大量超时。问题出在select for update拿到行锁事务内还查了其他表锁持有时间被拉长吞吐量自然上不去。我们的优化办法很简单去掉select for update把判断下沉到update语句里先尝试扣减再根据影响行数做后续处理。这样行锁持有时间被压缩到最短吞吐量至少提升了三倍。注意一点条件更新之后如果需要拿到扣减前后的余额可以单独在流水插入前select一次但这个select已经不在锁竞争中因为你的扣减事务还没提交其他事务无法修改余额所以查询结果依然是准确且可用的。2.4 分库分表下的余额扣减要么单账户单库要么引入分布式事务如果账户量大了得分库分表。这里有个原则一个账户的所有余额数据和流水数据必须路由到同一个库的同一张分表里。常见做法是account_id作为分片键account表和account_flow表都用account_id取模分片。这样单账户的扣减依然是一个本地事务不需要跨库。如果出现了跨账户转账之类的操作比如从A账户扣钱加到B账户而A和B在不同的分片上那就得引入分布式事务了。但转账这种场景在资金一致性要求极高的情况下我更建议走“本地消息表 消息队列”的方式做最终一致性而不是强依赖Seata的全局事务。原因也很直接全局事务会把两个分片上的资源锁在一起跨库锁等待更长吞吐量断崖下跌。这个我后面在第5章展开讲。3. 高并发扛峰值Redis缓存扣减的完整套路3.1 缓存扣减不是什么场景都该上先泼一盆冷水。如果你的系统QPS只有几百数据库条件更新完全够用千万别为了炫技引入Redis缓存和数据库的一致性难题会让你的维护成本翻几倍。但如果是秒杀、抢红包这种瞬时QPS上万而数据库单行更新最多支撑每秒一千多次的场景那就必须把余额扣减从数据库搬到Redis。Redis的扣减核心是单线程模型对一个key的INCR/DECR操作天然原子没有锁竞争。理论上一个Redis实例能扛10万 QPS的原子扣减这就是缓存扣减性能碾压数据库的底层原因。3.2 一个Lua脚本完成“检查余额扣减记录流水缓存”推荐用Lua脚本保证一系列Redis操作的原子性。脚本核心逻辑-- KEYS[1] 余额key -- KEYS[2] 已扣流水集合key -- ARGV[1] 扣减金额整数单位分 -- ARGV[2] 请求幂等ID -- 1. 判断幂等如果请求已存在返回1表示成功 local exists redis.call(SISMEMBER, KEYS[2], ARGV[2]) if exists 1 then return 1 end -- 2. 获取当前余额 local balance redis.call(GET, KEYS[1]) if not balance then return -1 -- 余额key不存在 end -- 3. 判断余额是否充足 if tonumber(balance) tonumber(ARGV[1]) then return 0 -- 余额不足 end -- 4. 扣减余额 redis.call(DECRBY, KEYS[1], ARGV[1]) -- 5. 记录幂等ID到集合保留近期去重信息 redis.call(SADD, KEYS[2], ARGV[2]) redis.call(EXPIRE, KEYS[2], 86400) return 1通过RedisCallback调用这个脚本返回值就是扣减结果。你可能注意到我把幂等集合的过期时间设成了1天这种设计适合大部分业务同一个请求ID只会短时间重试隔了一天再重试的请求基本可以认为是新的业务请求没必要永久保存。3.3 缓存扣减后怎么保证数据库最终一致这是最容易被问崩的一环也是大家最关心的。缓存里扣了钱数据库怎么同步答案是可靠消息异步落库。扣减成功后把一条“账户扣减流水消息”发到MQ。内容包含accountId, amount, requestId, flowType。消费者收到后执行第2章那个本地事务扣减数据库余额同时插入流水。这里有个“怎么保证消息不丢不漏”的问题可以这么做发送消息和写Redis扣减不一定能保证绝对原子。建议在Redis扣减成功后先往本地数据库的一张deduct_message表里插入一条待发送消息记录再异步发送到MQ。如果发送失败定时任务扫描这张表重发。消费者消费消息时必须幂等。好消息是我们用request_id作为数据库流水表的唯一键重复消费时插入流水会碰到唯一索引冲突冲突时直接返回成功不会重复扣减。这套链路下来Redis负责扛高并发数据库负责最终承重哪怕Redis崩溃最多就是在崩溃期间拒绝扣减或者降级到数据库扣减不会出现钱扣了但账对不上的情况。3.4 缓存与数据库不一致的三个风险点和兜底方案第一缓存存在数据库中但没有的“漂移”余额。比如Redis key被人误删重新从数据库load一份旧值。解决办法给余额key设置合理过期时间比如7天后台定时任务每隔几分钟把最新余额刷到Redis。第二并发扣减时Redis有余额数据库没余额。比如数据库余额是100Redis余额靠异步落库同步同步延迟期间Redis先扣了120等MQ落库时发现数据库余额不足。这种情况需要落库失败后做“回补”把Redis中多扣的金额加回去同时记录一条冲正流水并通知用户失败。第三Redis宕机。整个扣减入口要做降级直接把流量切到数据库扣减虽然性能下降但至少保证功能可用。这几个风险点必须在设计评审时讲清楚否则上线之后任何一个小概率事件都是P0事故。4. 入口流量治理用Sentinel给扣减接口装上阀门4.1 为什么扣减接口特别需要限流和熔断回到开头提到的热搜词alibaba sentinel、微服务高并发流量治理。扣减接口是整个交易链路的资金咽喉一旦被打崩影响的不只是自己还会拖垮下游账务库。它的特殊性在于即使你有Redis缓存扛着数据库落库依然有处理上限MQ消息积压到一定程度会导致数据不一致时间窗口被拉长。所以我通常会在这个链路上加上Sentinel实现三层防护前置限流超出预期峰值的流量直接返回“系统繁忙”热点防护同一个账户ID的极端频繁访问触发限流防止恶意刷单熔断降级如果下游Redis或数据库故障快速失败避免线程池被拖死4.2 热点参数限流同一个账户的扣减请求限流Sentinel里有一个非常贴合余额扣减场景的能力热点参数限流。它的作用是对指定的参数值进行单独的QPS统计。比如我们想限制“同一个accountId每秒最多只能扣减100次”多余的请求直接拒绝既保护了账户行的锁竞争又不会影响其他账户的正常扣减。配置上用注解方式最简单SentinelResource( value deductBalance, blockHandler deductBlockHandler, fallback deductFallback ) public ResultBoolean deductBalance(String accountId, BigDecimal amount, String requestId) { // 业务扣减逻辑 }然后在控制台或代码规则里定义热点规则ParamFlowRule rule new ParamFlowRule(deductBalance) .setParamIdx(0) // 第一个参数是accountId .setCount(100) // 同一账户每秒最多100次 .setDurationInSec(1); ParamFlowItem item new ParamFlowItem() .setObject(String.valueOf(COLD_ACCOUNT_ID)) // 对特定冷账户单独设置 .setCount(10); rule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(rule));当我设置paramIdx0时Sentinel会为每个accountId单独维护一个QPS计数器。某些平台补贴账户是全站共用的大账户流量很高可以用热点参数例外项单独设置更小的阈值防止它被洪水流量打垮。4.3 线程池隔离与信号量隔离扣减接口要用的两种隔离模式除了热参限流接口还需要做隔离。Sentinel提供了两种常见模式简单说线程池隔离给每个资源分配独立线程池适合需要控制线程数、降低阻塞影响的场景。但线程池本身有上下文切换成本高QPS场景不太推荐。信号量隔离扣减接口使用信号量控制并发线程数不额外创建线程。因为扣减接口通常耗时极短几十毫秒信号量隔离更轻量性能损耗小。我给扣减接口推荐信号量隔离核心参数是maxConcurrentRequests。举个例子如果扣减接口平均耗时50ms那理论单机单线程只能处理20 QPS。如果想支撑500 QPS至少需要25个并发线程。但你不想让机器被扣减请求占满就设置信号量上限为50或100超出并发的请求快速失败。实际规则代码DegradeRule degradeRule new DegradeRule(deductBalance) .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO) // 异常比例熔断 .setCount(0.3) // 异常比例超过30% .setTimeWindow(10) // 熔断10秒 .setMinRequestAmount(20); // 最小请求数当扣减Redis异常、数据库连接池满导致异常率升高Sentinel会自动熔断10秒让请求快速失败而不是继续挂起消耗资源。这10秒给了下游恢复的时间。4.4 实际接入Sentinel时最容易踩的坑第一没有定义blockHandler和fallback的区别。blockHandler处理的是“被限流/降级拒绝”的请求fallback处理的是“业务本身抛异常”的请求。很多初学者只写fallback被限流后还是会往fallback里挤导致限流失效。正确做法是blockHandler返回“系统繁忙”fallback返回“扣减异常”。第二Sentinel规则的持久化没做好。默认规则保存在内存里一旦应用重启规则全没。需要把规则推到Nacos或其他配置中心用ReadableDataSource做持久化。第三对热点参数限流采用默认参数位置搞错。注解方式下paramIdx是方法的参数下标从0开始不是形参名。我把这个坑讲出来因为真实项目里有人因为把下标写成1导致热点规则一直不生效请求一路打到数据库最后把库干穿了。5. 一致性兜底对账、幂等、最终一致性的一条龙设计5.1 为什么你不能完全相信任何单点组件Redis会丢keyMQ会重复消息数据库网络会闪断就算你用了分布式事务性能也会让你怀疑人生。所以高并发余额扣减系统的设计哲学是接受任何时刻都可能出现不一致但保证最终一致。我通常会把一致性校验做成一个独立对账服务定时扫描“扣减流水消息表”和“账户流水表”。凡是本地消息表存在但账户流水表不存在的记录说明消息没能成功异步落库需要重新投递。类似这样-- 待对账消息表 SELECT id, account_id, amount, request_id, status FROM deduct_message WHERE status SENT AND create_time DATE_SUB(NOW(), INTERVAL 5 MINUTE) LIMIT 100;如果一条消息发出超过5分钟还没有在账户流水表找到对应request_id就重推一次。重推几轮后还是失败就钉钉告警人工介入。这属于最土但是最有效的兜底方案。5.2 幂等设计不是一张唯一表就结束的在扣减链路中幂等至少要在两个地方做Redis层通过幂等ID集合防止同一请求重复扣减Redis余额。数据库层通过流水表request_id唯一索引防止重复落库。对外返回值如果重复请求打到接口接口要能识别并返回“扣减成功”或“之前的结果”而不是抛异常。更细一点幂等判断要区分“已成功”和“处理中”。处理中的请求并发重入时最好用分布式锁或Redis锁挡一下。比如同一个requestId同时来两个请求两个都去查流水表都没查到然后都去扣余额就透了。所以扣减前最好加一个Redis分布式锁String lockKey deduct:lock: requestId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (!locked) { throw new RepeatRequestException(重复请求); }加锁后第二个请求会拿不到锁直接返回“请求处理中”等第一个请求把流水写库成功重试时就能命中幂等。5.3 不用分布式事务的成本与收益如果资金系统要求强一致是不是必须用Seata我个人的观点是分场景。像“单账户扣减”这种天然本地事务能解决的绝不引入分布式事务。像“跨账户转账”这种业务上可以做成“A账户扣减 消息驱动B账户入账”也就是最终一致性方案。这样牺牲了秒级强一致但换来了系统吞吐量和高可用。最终一致性方案最怕的就是消息丢失后没人发现。所以必须有上述对账链路且对账频率要足够高。以余额类系统为例建议5分钟一个小对账1小时一个全量对账每天凌晨做一次总账核对。这里的“核对”就是把所有账户的期初余额、期间扣减流水、期末余额汇总出来对比总账是否平了。5.4 兜底逻辑不要忘了“冲正”当Redis已经扣减成功、数据库异步落库失败且无法重试时比如账户被冻结必须给用户做冲正。冲正也是一条特殊的流水金额为负数记录原请求ID和原流水的关联。冲正之后要通知上游业务方“扣减失败”。这里有一个人工可感知的细节用户在秒杀时看到一个“已扣款”的提示然后过了几十秒变成“退款成功”体验很糟糕但如果不下发冲正账就永远不平了。所以宁可体验差一点也要保证账目正确。6. 压测出的真相限流参数与扣减SQL的调优记录6.1 一次模拟真实扣减压测的结果说一个我之前做过的实际压测环境是两个应用节点8核8G数据库是MySQL 8.0Redis是6.x使用JMeter模拟2000个用户同时在100秒内对同一个账户发起扣减。第一轮纯数据库条件更新不带Redis单机QPS大约420随着并发线程数增加到150出现大量Lock wait timeout报错接口成功率跌到97%平均响应时间飙升到240ms。第二轮加上Redis Lua脚本扣减Sentinel热点限流同一账户每秒100次QPS直接稳定在5000数据库落库通过MQ削峰数据库的QPS被平滑到300~400没有任何锁等待接口成功率99.99%。这个对比非常直观数据库不是不能扛而是扛不住“瞬时尖刺”Redis加MQ的作用是把尖刺削平让数据库稳定处理均摊流量。6.2 Sentinel参数调整的心得ParamFlowRule的count不要拍脑袋。先用压测得出单个账户数据库落库的极限比如在安全水位下数据库单行更新最多500 TPS那么Redis层同一个账户限流就应该设为每秒400次留20%余量。DegradeRule的timeWindow建议设为10~30秒。太短下游没恢复又放流量进去太长业务损失又太大。熔断的minRequestAmount建议20否则在低流量时段很容易被几个小波动触发误熔断。另外提醒一句Sentinel控制台不是必须部署的。如果你不想引入控制台依赖完全可以通过代码加载规则。控制台的价值在于动态调整阈值但生产环境规则最好固化在Nacos配置中心改配置也要走审批流程。6.3 数据库扣减SQL的调优细节除了条件更新和索引优化还有几个平时不注意的点account_flow表要单独建索引否则流水表膨胀后查询会拖慢整个事务。建索引建议(account_id, create_time)联合索引支撑订单查询和对账扫描。余额字段建议使用DECIMAL(12,2)不要用FLOAT/DOUBLE避免浮点误差导致对账不平。扣减事务里不要再查询“用户VIP等级”“优惠券”等同库其他表。事务里操作的行和表越少锁时间越短。把非必要的查询放到事务外先查出必要数据再开启事务执行扣减。如果单账户确实存在极高并发比如平台补贴账户还可以把账户余额拆分为多个子余额桶比如余额桶1-10随机选桶扣减。这个方案最终对账会比较麻烦慎用。6.4 压测时最容易忽略的Redis细节Redis扣减时key的过期策略要设计好。如果把余额key设置为永不过期万一数据不一致永远得不到自动恢复。建议设置过期时间比如7天同时做定时刷新任务。但要注意EXPIRE用在余额key上时如果key到期了DB里的余额又没刷过来会导致扣减直接返回“余额不存在”。所以缓存刷新任务必须比过期时间更早、更频繁地执行建议每5分钟刷新一次。另外扣减金额在Redis中别用Double转成整数分存储比如balance: 10000表示100.00元。Lua脚本中tonumber处理整数更安全也能避免浮点误差。这条细节看起来小但对账的时候会让你少掉很多头发。最后分享一个排查扣减问题的小经验如果你在线上发现“扣减资金平不了账”先别急着查代码逻辑直接拉三样东西request_id对应的MQ消息记录、Redis扣减Lua日志、数据库流水表记录。按时间线排一下通常很快能定位到是消息丢失、重复消费还是Redis key漂移。这比盯着一个方法读十遍高效得多。另外强烈建议在Lua脚本和数据库扣减入口都打印包含request_id的日志方便串联整条链路。别嫌日志多出问题的时候日志就是你唯一能抓住的救命稻草。
高并发下怎么做余额扣减这个问题我至少被问过十次面试问、项目评审问、系统故障复盘也问。很多人第一反应是“用事务啊两条update搞定”听起来没错但一旦压到5000 QPS你会立刻发现数据库的InnoDB行锁变成一把巨大的串行闸门账扣不准、超扣、死锁、接口超时全来了。今天这篇文章我结合自己实操过的扣减系统从数据库方案到Redis缓存扣减再串到Sentinel流量治理把高并发余额扣减这条链路掰开揉碎希望给正在做账户、钱包、积分系统的你一些真正能落地的参考。写这篇内容之前我大概梳理了一下会讲到四个关键词幂等、无锁化、最终一致性、限流削峰。你把这四个词理解透了不管是用数据库锁还是引入中间件心里都有数。这篇文章适合正在做订单支付、钱包转账、库存扣减、积分消耗这类强一致事务场景的开发者也适合想搞明白Sentinel在真实扣减场景里怎么用的后端同学。1. 余额扣减为什么难先看清三个隐藏敌人1.1 你以为的扣减只是“减法”实际是“共享资源的并发写”余额扣减本质上是一个共享账户的写操作。比如你账户里有100元几十个请求同时要扣如果并发没控制好最终余额可能变成负数或者出现“超扣”现象。很多人第一直觉是加一个synchronized或者Lock锁但这只解决单机问题一旦服务部署多副本JVM锁瞬间失效。再往后想到数据库select for update又会出现另一个问题行锁竞争。我见过一个比较典型的场景秒杀活动中同一个热销账户比如平台补贴账户被所有用户共享扣减结果数据库那一行的行锁等待直接打满了连接池。数据库的CPU不高事务提交时间也不长但请求就是全部堆积在“锁等待”上。这种问题不是SQL优化能解决的而是锁粒度太粗。1.2 隐藏敌人一事务重试造成的重复扣高并发下接口可能会超时客户端会重试。如果你只是写了一个update account set balance balance - amount where id ?重试两次就扣两次。很多人说“重试请求我们通过唯一请求号判断”但判断去重的代码和扣减代码不在同一个事务里依然会有漏洞。一旦去重表和账户表不在同一个本地事务里就会出现扣了钱但标记没写入下一次重试照样扣成功。这个问题的本质是扣减动作必须幂等。也就是同一个请求无论执行多少次效果跟只执行一次一样。别以为简单做起来需要考虑的东西很多后面第3章我会细说。1.3 隐藏敌人二并发扣减导致超扣数据库都不报错看这个经典案例-- 伪代码先查询余额再判断是否够扣最后执行扣减 SELECT balance FROM account WHERE id 100; -- 结果50 if (balance 20) { // 判断通过准备扣20 UPDATE account SET balance balance - 20 WHERE id 100; }如果不是原子操作两个请求同时查到余额都是50同时判断可以扣20然后都执行update最终余额是10而不是30不会其实是30算一下两个20都成功50-20-2010那原本只剩下10却放了两个20出去就是超扣了10元。这还只是两并发高并发下会更夸张。要完全解决超扣必须把“余额判断”和“余额扣减”合成一个原子操作数据库里最直接的方式是UPDATE ... WHERE balance amount让数据库帮你做条件判断用行锁的原子性把检查和扣减合二为一。1.4 隐藏敌人三数据库行锁成为性能瓶颈即便你把超扣问题解决了只用一个update语句保持原子性高并发下的行锁依然可怕。假设单行数据的update执行耗时1ms那同一行理论上每秒最多只能串行执行1000次。一旦瞬时并发达到5000其余4000个请求都要排队等锁超过数据库innodb_lock_wait_timeout默认的50秒直接报Lock wait timeout exceeded。这就是余额扣减难的核心矛盾既要保证同一行并发扣减的强一致又要尽量减轻行锁对吞吐量的影响。怎么破靠单一数据库方案很难必须分层流量入口先削峰数据库层用条件更新兜底中间再加一层缓存扣减扛峰值。2. 数据库层的正统做法条件更新加流水事务2.1 保证原子性把判断和扣减写进同一条SQL常规账务系统里最稳的扣减SQL长这样UPDATE account SET balance balance - #{amount}, update_time NOW() WHERE id #{accountId} AND balance #{amount} AND status 1;balance #{amount}这个条件非常关键。它让数据库在行锁内部完成“余额够不够”的校验不够的话影响行数为0你再根据影响行数判断是否失败。如果影响行数为0说明余额不足或者账户异常返回业务失败影响行数为1说明扣减成功。这里需要注意的一点如果你用了MyBatis-Plus这类工具别拿实体类先selectById再setBalance再updateById那个流程没法保证原子性。怼着Mapper写一条带条件的update才是正确姿势。2.2 流水表扣减不能只改余额必须留痕只改余额出了问题没法追溯。正儿八经的扣减应该跟着一条流水记录比如-- 账户流水表 CREATE TABLE account_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_id BIGINT NOT NULL, request_id VARCHAR(64) NOT NULL, amount DECIMAL(12,2) NOT NULL, flow_type TINYINT NOT NULL COMMENT 1-扣减 2-充值 3-冻结 4-解冻, before_balance DECIMAL(12,2) NOT NULL, after_balance DECIMAL(12,2) NOT NULL, create_time DATETIME NOT NULL, UNIQUE KEY uk_request_id(request_id) ) ENGINEInnoDB;request_id唯一约束这步是幂等的关键。每次扣减请求带一个全局唯一的请求ID流水表插入时如果违反唯一约束说明这个请求已经处理过直接返回上次的结果。余额更新和流水插入必须在同一个数据库事务里保证“余额变了但流水没记”这类问题不发生。这也是本地事务方案最常见的姿势Transactional(rollbackFor Exception.class) public void deduct(Long accountId, BigDecimal amount, String requestId) { // 1. 幂等检查查流水表是否已存在 request_id // 2. 条件更新余额 int count accountMapper.deductBalance(accountId, amount); if (count 0) { throw new InsufficientBalanceException(余额不足); } // 3. 插入流水 accountFlowMapper.insert(accountId, requestId, amount); }2.3 为什么“先查后扣”容易踩坑实际项目怎么改我接手过一个老系统代码里就是先select ... for update锁行再判余额再update。当时压测一上500并发就大量超时。问题出在select for update拿到行锁事务内还查了其他表锁持有时间被拉长吞吐量自然上不去。我们的优化办法很简单去掉select for update把判断下沉到update语句里先尝试扣减再根据影响行数做后续处理。这样行锁持有时间被压缩到最短吞吐量至少提升了三倍。注意一点条件更新之后如果需要拿到扣减前后的余额可以单独在流水插入前select一次但这个select已经不在锁竞争中因为你的扣减事务还没提交其他事务无法修改余额所以查询结果依然是准确且可用的。2.4 分库分表下的余额扣减要么单账户单库要么引入分布式事务如果账户量大了得分库分表。这里有个原则一个账户的所有余额数据和流水数据必须路由到同一个库的同一张分表里。常见做法是account_id作为分片键account表和account_flow表都用account_id取模分片。这样单账户的扣减依然是一个本地事务不需要跨库。如果出现了跨账户转账之类的操作比如从A账户扣钱加到B账户而A和B在不同的分片上那就得引入分布式事务了。但转账这种场景在资金一致性要求极高的情况下我更建议走“本地消息表 消息队列”的方式做最终一致性而不是强依赖Seata的全局事务。原因也很直接全局事务会把两个分片上的资源锁在一起跨库锁等待更长吞吐量断崖下跌。这个我后面在第5章展开讲。3. 高并发扛峰值Redis缓存扣减的完整套路3.1 缓存扣减不是什么场景都该上先泼一盆冷水。如果你的系统QPS只有几百数据库条件更新完全够用千万别为了炫技引入Redis缓存和数据库的一致性难题会让你的维护成本翻几倍。但如果是秒杀、抢红包这种瞬时QPS上万而数据库单行更新最多支撑每秒一千多次的场景那就必须把余额扣减从数据库搬到Redis。Redis的扣减核心是单线程模型对一个key的INCR/DECR操作天然原子没有锁竞争。理论上一个Redis实例能扛10万 QPS的原子扣减这就是缓存扣减性能碾压数据库的底层原因。3.2 一个Lua脚本完成“检查余额扣减记录流水缓存”推荐用Lua脚本保证一系列Redis操作的原子性。脚本核心逻辑-- KEYS[1] 余额key -- KEYS[2] 已扣流水集合key -- ARGV[1] 扣减金额整数单位分 -- ARGV[2] 请求幂等ID -- 1. 判断幂等如果请求已存在返回1表示成功 local exists redis.call(SISMEMBER, KEYS[2], ARGV[2]) if exists 1 then return 1 end -- 2. 获取当前余额 local balance redis.call(GET, KEYS[1]) if not balance then return -1 -- 余额key不存在 end -- 3. 判断余额是否充足 if tonumber(balance) tonumber(ARGV[1]) then return 0 -- 余额不足 end -- 4. 扣减余额 redis.call(DECRBY, KEYS[1], ARGV[1]) -- 5. 记录幂等ID到集合保留近期去重信息 redis.call(SADD, KEYS[2], ARGV[2]) redis.call(EXPIRE, KEYS[2], 86400) return 1通过RedisCallback调用这个脚本返回值就是扣减结果。你可能注意到我把幂等集合的过期时间设成了1天这种设计适合大部分业务同一个请求ID只会短时间重试隔了一天再重试的请求基本可以认为是新的业务请求没必要永久保存。3.3 缓存扣减后怎么保证数据库最终一致这是最容易被问崩的一环也是大家最关心的。缓存里扣了钱数据库怎么同步答案是可靠消息异步落库。扣减成功后把一条“账户扣减流水消息”发到MQ。内容包含accountId, amount, requestId, flowType。消费者收到后执行第2章那个本地事务扣减数据库余额同时插入流水。这里有个“怎么保证消息不丢不漏”的问题可以这么做发送消息和写Redis扣减不一定能保证绝对原子。建议在Redis扣减成功后先往本地数据库的一张deduct_message表里插入一条待发送消息记录再异步发送到MQ。如果发送失败定时任务扫描这张表重发。消费者消费消息时必须幂等。好消息是我们用request_id作为数据库流水表的唯一键重复消费时插入流水会碰到唯一索引冲突冲突时直接返回成功不会重复扣减。这套链路下来Redis负责扛高并发数据库负责最终承重哪怕Redis崩溃最多就是在崩溃期间拒绝扣减或者降级到数据库扣减不会出现钱扣了但账对不上的情况。3.4 缓存与数据库不一致的三个风险点和兜底方案第一缓存存在数据库中但没有的“漂移”余额。比如Redis key被人误删重新从数据库load一份旧值。解决办法给余额key设置合理过期时间比如7天后台定时任务每隔几分钟把最新余额刷到Redis。第二并发扣减时Redis有余额数据库没余额。比如数据库余额是100Redis余额靠异步落库同步同步延迟期间Redis先扣了120等MQ落库时发现数据库余额不足。这种情况需要落库失败后做“回补”把Redis中多扣的金额加回去同时记录一条冲正流水并通知用户失败。第三Redis宕机。整个扣减入口要做降级直接把流量切到数据库扣减虽然性能下降但至少保证功能可用。这几个风险点必须在设计评审时讲清楚否则上线之后任何一个小概率事件都是P0事故。4. 入口流量治理用Sentinel给扣减接口装上阀门4.1 为什么扣减接口特别需要限流和熔断回到开头提到的热搜词alibaba sentinel、微服务高并发流量治理。扣减接口是整个交易链路的资金咽喉一旦被打崩影响的不只是自己还会拖垮下游账务库。它的特殊性在于即使你有Redis缓存扛着数据库落库依然有处理上限MQ消息积压到一定程度会导致数据不一致时间窗口被拉长。所以我通常会在这个链路上加上Sentinel实现三层防护前置限流超出预期峰值的流量直接返回“系统繁忙”热点防护同一个账户ID的极端频繁访问触发限流防止恶意刷单熔断降级如果下游Redis或数据库故障快速失败避免线程池被拖死4.2 热点参数限流同一个账户的扣减请求限流Sentinel里有一个非常贴合余额扣减场景的能力热点参数限流。它的作用是对指定的参数值进行单独的QPS统计。比如我们想限制“同一个accountId每秒最多只能扣减100次”多余的请求直接拒绝既保护了账户行的锁竞争又不会影响其他账户的正常扣减。配置上用注解方式最简单SentinelResource( value deductBalance, blockHandler deductBlockHandler, fallback deductFallback ) public ResultBoolean deductBalance(String accountId, BigDecimal amount, String requestId) { // 业务扣减逻辑 }然后在控制台或代码规则里定义热点规则ParamFlowRule rule new ParamFlowRule(deductBalance) .setParamIdx(0) // 第一个参数是accountId .setCount(100) // 同一账户每秒最多100次 .setDurationInSec(1); ParamFlowItem item new ParamFlowItem() .setObject(String.valueOf(COLD_ACCOUNT_ID)) // 对特定冷账户单独设置 .setCount(10); rule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(rule));当我设置paramIdx0时Sentinel会为每个accountId单独维护一个QPS计数器。某些平台补贴账户是全站共用的大账户流量很高可以用热点参数例外项单独设置更小的阈值防止它被洪水流量打垮。4.3 线程池隔离与信号量隔离扣减接口要用的两种隔离模式除了热参限流接口还需要做隔离。Sentinel提供了两种常见模式简单说线程池隔离给每个资源分配独立线程池适合需要控制线程数、降低阻塞影响的场景。但线程池本身有上下文切换成本高QPS场景不太推荐。信号量隔离扣减接口使用信号量控制并发线程数不额外创建线程。因为扣减接口通常耗时极短几十毫秒信号量隔离更轻量性能损耗小。我给扣减接口推荐信号量隔离核心参数是maxConcurrentRequests。举个例子如果扣减接口平均耗时50ms那理论单机单线程只能处理20 QPS。如果想支撑500 QPS至少需要25个并发线程。但你不想让机器被扣减请求占满就设置信号量上限为50或100超出并发的请求快速失败。实际规则代码DegradeRule degradeRule new DegradeRule(deductBalance) .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO) // 异常比例熔断 .setCount(0.3) // 异常比例超过30% .setTimeWindow(10) // 熔断10秒 .setMinRequestAmount(20); // 最小请求数当扣减Redis异常、数据库连接池满导致异常率升高Sentinel会自动熔断10秒让请求快速失败而不是继续挂起消耗资源。这10秒给了下游恢复的时间。4.4 实际接入Sentinel时最容易踩的坑第一没有定义blockHandler和fallback的区别。blockHandler处理的是“被限流/降级拒绝”的请求fallback处理的是“业务本身抛异常”的请求。很多初学者只写fallback被限流后还是会往fallback里挤导致限流失效。正确做法是blockHandler返回“系统繁忙”fallback返回“扣减异常”。第二Sentinel规则的持久化没做好。默认规则保存在内存里一旦应用重启规则全没。需要把规则推到Nacos或其他配置中心用ReadableDataSource做持久化。第三对热点参数限流采用默认参数位置搞错。注解方式下paramIdx是方法的参数下标从0开始不是形参名。我把这个坑讲出来因为真实项目里有人因为把下标写成1导致热点规则一直不生效请求一路打到数据库最后把库干穿了。5. 一致性兜底对账、幂等、最终一致性的一条龙设计5.1 为什么你不能完全相信任何单点组件Redis会丢keyMQ会重复消息数据库网络会闪断就算你用了分布式事务性能也会让你怀疑人生。所以高并发余额扣减系统的设计哲学是接受任何时刻都可能出现不一致但保证最终一致。我通常会把一致性校验做成一个独立对账服务定时扫描“扣减流水消息表”和“账户流水表”。凡是本地消息表存在但账户流水表不存在的记录说明消息没能成功异步落库需要重新投递。类似这样-- 待对账消息表 SELECT id, account_id, amount, request_id, status FROM deduct_message WHERE status SENT AND create_time DATE_SUB(NOW(), INTERVAL 5 MINUTE) LIMIT 100;如果一条消息发出超过5分钟还没有在账户流水表找到对应request_id就重推一次。重推几轮后还是失败就钉钉告警人工介入。这属于最土但是最有效的兜底方案。5.2 幂等设计不是一张唯一表就结束的在扣减链路中幂等至少要在两个地方做Redis层通过幂等ID集合防止同一请求重复扣减Redis余额。数据库层通过流水表request_id唯一索引防止重复落库。对外返回值如果重复请求打到接口接口要能识别并返回“扣减成功”或“之前的结果”而不是抛异常。更细一点幂等判断要区分“已成功”和“处理中”。处理中的请求并发重入时最好用分布式锁或Redis锁挡一下。比如同一个requestId同时来两个请求两个都去查流水表都没查到然后都去扣余额就透了。所以扣减前最好加一个Redis分布式锁String lockKey deduct:lock: requestId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (!locked) { throw new RepeatRequestException(重复请求); }加锁后第二个请求会拿不到锁直接返回“请求处理中”等第一个请求把流水写库成功重试时就能命中幂等。5.3 不用分布式事务的成本与收益如果资金系统要求强一致是不是必须用Seata我个人的观点是分场景。像“单账户扣减”这种天然本地事务能解决的绝不引入分布式事务。像“跨账户转账”这种业务上可以做成“A账户扣减 消息驱动B账户入账”也就是最终一致性方案。这样牺牲了秒级强一致但换来了系统吞吐量和高可用。最终一致性方案最怕的就是消息丢失后没人发现。所以必须有上述对账链路且对账频率要足够高。以余额类系统为例建议5分钟一个小对账1小时一个全量对账每天凌晨做一次总账核对。这里的“核对”就是把所有账户的期初余额、期间扣减流水、期末余额汇总出来对比总账是否平了。5.4 兜底逻辑不要忘了“冲正”当Redis已经扣减成功、数据库异步落库失败且无法重试时比如账户被冻结必须给用户做冲正。冲正也是一条特殊的流水金额为负数记录原请求ID和原流水的关联。冲正之后要通知上游业务方“扣减失败”。这里有一个人工可感知的细节用户在秒杀时看到一个“已扣款”的提示然后过了几十秒变成“退款成功”体验很糟糕但如果不下发冲正账就永远不平了。所以宁可体验差一点也要保证账目正确。6. 压测出的真相限流参数与扣减SQL的调优记录6.1 一次模拟真实扣减压测的结果说一个我之前做过的实际压测环境是两个应用节点8核8G数据库是MySQL 8.0Redis是6.x使用JMeter模拟2000个用户同时在100秒内对同一个账户发起扣减。第一轮纯数据库条件更新不带Redis单机QPS大约420随着并发线程数增加到150出现大量Lock wait timeout报错接口成功率跌到97%平均响应时间飙升到240ms。第二轮加上Redis Lua脚本扣减Sentinel热点限流同一账户每秒100次QPS直接稳定在5000数据库落库通过MQ削峰数据库的QPS被平滑到300~400没有任何锁等待接口成功率99.99%。这个对比非常直观数据库不是不能扛而是扛不住“瞬时尖刺”Redis加MQ的作用是把尖刺削平让数据库稳定处理均摊流量。6.2 Sentinel参数调整的心得ParamFlowRule的count不要拍脑袋。先用压测得出单个账户数据库落库的极限比如在安全水位下数据库单行更新最多500 TPS那么Redis层同一个账户限流就应该设为每秒400次留20%余量。DegradeRule的timeWindow建议设为10~30秒。太短下游没恢复又放流量进去太长业务损失又太大。熔断的minRequestAmount建议20否则在低流量时段很容易被几个小波动触发误熔断。另外提醒一句Sentinel控制台不是必须部署的。如果你不想引入控制台依赖完全可以通过代码加载规则。控制台的价值在于动态调整阈值但生产环境规则最好固化在Nacos配置中心改配置也要走审批流程。6.3 数据库扣减SQL的调优细节除了条件更新和索引优化还有几个平时不注意的点account_flow表要单独建索引否则流水表膨胀后查询会拖慢整个事务。建索引建议(account_id, create_time)联合索引支撑订单查询和对账扫描。余额字段建议使用DECIMAL(12,2)不要用FLOAT/DOUBLE避免浮点误差导致对账不平。扣减事务里不要再查询“用户VIP等级”“优惠券”等同库其他表。事务里操作的行和表越少锁时间越短。把非必要的查询放到事务外先查出必要数据再开启事务执行扣减。如果单账户确实存在极高并发比如平台补贴账户还可以把账户余额拆分为多个子余额桶比如余额桶1-10随机选桶扣减。这个方案最终对账会比较麻烦慎用。6.4 压测时最容易忽略的Redis细节Redis扣减时key的过期策略要设计好。如果把余额key设置为永不过期万一数据不一致永远得不到自动恢复。建议设置过期时间比如7天同时做定时刷新任务。但要注意EXPIRE用在余额key上时如果key到期了DB里的余额又没刷过来会导致扣减直接返回“余额不存在”。所以缓存刷新任务必须比过期时间更早、更频繁地执行建议每5分钟刷新一次。另外扣减金额在Redis中别用Double转成整数分存储比如balance: 10000表示100.00元。Lua脚本中tonumber处理整数更安全也能避免浮点误差。这条细节看起来小但对账的时候会让你少掉很多头发。最后分享一个排查扣减问题的小经验如果你在线上发现“扣减资金平不了账”先别急着查代码逻辑直接拉三样东西request_id对应的MQ消息记录、Redis扣减Lua日志、数据库流水表记录。按时间线排一下通常很快能定位到是消息丢失、重复消费还是Redis key漂移。这比盯着一个方法读十遍高效得多。另外强烈建议在Lua脚本和数据库扣减入口都打印包含request_id的日志方便串联整条链路。别嫌日志多出问题的时候日志就是你唯一能抓住的救命稻草。
