高并发下怎么做余额扣减？

单个 user 哪来的高并发?

你想问的是不是库存?

行级锁应该就够你用了。

分布式锁,队列,单线程

@runningman 行锁 怎么避免 死锁

一楼说出了核心，虽然银行类业务用户多，但是架不住最大的客户操作完一个交易也是需要时间的，这时间不会导致并发

@Jooooooooo 那库存这种问题 应该怎么解决？

如果并发不会很高的话不用在数据库上加锁
1. 要扣的钱为 A ，先查 amount 当前值为 B ，代码中判断 B >= A
2. 然后执行 update xxx set amount = amount - A where amount = B
3. 执行看影响行数，如果为 0 ，重新从第 1 步执行
一般只需要重试一次。

update xxxxx set xxxx where 余额>xx 余额 用 innodb 本身就有行锁,失败返回异常，这点时间肯定要等的

乐观锁就够了，修改时判断一下余额与你之前查到的余额是否一致。

一锁 二查 三更新

@ElmerZhang
@dongtingyue
@coderxy

看三位的回答中好像没有提到事务，不用事务的话遇到意外停机怎么办呢？或者是我理解错了

@CEBBCAT 同时更新多个才要事务，例如给一个人加余额，另一个人减余额。

https://www.51cto.com/article/720873.html

并发扣款，如何保证一致性
沈剑 大佬的文章可以看看

update users set balance = balance - 1 where user_id = 123 and balance >= 1;
只在余额大于 1 时扣除用户 123 的 1 块钱

@richangfan 假设网关、框架重试，会多扣款，解决手段：
1 、悲观锁，使用分布式锁
2 、乐观锁，使用 CAS ，select 得到的 balance 作为 update 的 where 条件，并添加 ver 条件解决 ABA 问题

不要做无意义的事情，15 楼的方法可以很好的解决 OP 你的这个问题。

@jobmailcn 是的。我看楼主这个 case 就是需要一边扣钱，一边发放什么东西。

@orzwalker111 是的，我们也是使用 cas ，更新时判断 version ，如果被其他事物更新到 version + 1 了，就 select 新的 balance 和 version 出来，然后基于新 version 做判断，新 balance 做更新。

try {
BEGIN;
SELECT balance FROM userinfo WHERE user_id = xxx FOR UPDATE;
逻辑判断，有问题就 throw Exception
UPDATE userinfo...
COMIT;
} catch {
ROLLBACK;
}

@hhhhhh123 #8
库存的话
如果是热点 SKU 可以分段锁 比如有 1w 个库存 可以分成 10 个 1000 出来

事务加行锁，扣款交易可以先入库，再用异步任务按顺序执行交易扣款。有些第三方代扣服务就是这样设计的

乐观锁即可

实操都是 tcc ，两步提交

你的想法怕慢 实际不会很慢 并发是同等触发 实际触发时并没有的

@love2328 有一次网卡，连点很多下，10 冲了 50

用事务不就完事了吗？ 怎么都不提事务的？

用户级别并发锁行锁不就可以了吗

改个余额
加订单入库
加资金流水能有几张表
能慢到哪里去啊
你这个下单接口高峰 qps 能有 1000 吗

如果是扣库存，只要保证别 100 个商品，结果 10000 个请求打到数据库上、也别同一时间点 100 个请求全都在数据库上扣同一个商品，就没什么可担心的，数据库的性能足够。
扣余额就更简单了，限制下不要让一个用户同时发起一堆请求（这本来也该限制吧）
实现上可以用 update cas ，但存在限制不方便时直接 Serializable 性能不一定差（ PostgreSQL ）

@xyjincan 点的时候 没有置等待 ? 要么场景不够经验 要么坑用户

@ElmerZhang update xxx set amount = amount - A where amount = B where amount-A>0

@ElmerZhang 那不如直接 update xxx set amount = amount - A where amount > A (

用 redis 锁不就好了吗?

我觉得在 update 时 「 where 余额 = 扣款前查询的余额」这一步就能规避重复操作的风险，这不能当 standard procedure 吗？

高并发扣减：
1. 合并请求，在保证事务的前提下，将多个扣款请求合并操作，这样只需要做一次锁操作和写操作。
2. 拆分账户，将热点账户的余额账户拆分成多个子余额账户，以此来降低单个账户扣减操作的并发度。
3. 使用内存数据库扣减，并异步写日志，所有日志结果可以回溯账户余额结果，和内存数据库做对账。

@noogel 1 和 2 的处理对热点账户的处理都只考虑怎么解决记账问题
1 的问题在于合并记账后余额不足的怎么处理，可能拆分记有些还能成功
2 的问题在于多个账户如何协同管理
3 的实现最终还是会碰到热点账户问题，当然效率比起数据库来说要好很多了
不清楚是否有相应的成熟业务的解决方案文章能看看

@ElmerZhang 我理解 第一步和第二步 ，第三部不是特别理解， 为啥只递归一次？

@vanillacloud @codehz @8520ccc @richangfan 如果这样的话， 同时有俩个 一个扣款 10 块 一个扣款 5 块。 这样只会执行其中的一个余额。 另外一个就不会执行。 我觉得 8 楼的 第三个条件挺好， 但是递归次数 又不好拿捏。

我的新思路是 ： 只要保证每个请求都是正确的扣钱请求。 然后参考 8 楼， 当然第三个条件只能是一直递归下去， 吧所有的请求都给操作完。

两个方案
方案一： 悲观锁
consume(var accountId,var amount) {
//先查询余额
"select accountId,balance from xxx where accountId = $accountId for update";
//计算
$new_balance = $old_balance - $amount;
update xxx balance = $new_balance where accountId = $accountId
}

方案二: 乐观锁
consume(var accountId,var amount) {
flag = false,retires = 3
// CAS + 重试
while(!flag && retries > 0) {
flag = consume0(accountId,amount);
retries--;
}

}

boolean consume0(var accountId,var amount) {
//先查询余额（只是查询不加锁）
"select accountId,balance from xxx where accountId = $accountId";
//计算
$new_balance = $old_balance - $amount;
row = update xxx balance = $new_balance where accountId = $accountId and balance = $old_balance
return row == 1;
}

备选方案：（高并发，单个用户消费并发超过 1000 ）缓存 + 消息中间件，
用户消费操作是扣减缓存中余额（注意这里原子性查询和扣减两个动作，例如 redis 可以使用 lua ）， 扣减成功发送消息到消息队列更新数据库。