nuomiphp
正在加载…
请使用更现代的浏览器并启用 JavaScript 以获得最佳浏览体验。
加载论坛时出错,请强制刷新页面重试。
高并发下怎么做余额扣减?
rqrq
try {
BEGIN;
SELECT balance FROM userinfo WHERE user_id = xxx FOR UPDATE;
逻辑判断,有问题就 throw Exception
UPDATE userinfo...
COMIT;
} catch {
ROLLBACK;
}
rqrq
BEGIN 写在 try 外面。
brust
hhhhhh123
#8库存的话如果是热点 SKU 可以分段锁 比如有 1w 个库存 可以分成 10 个 1000 出来
yogogo
事务加行锁,扣款交易可以先入库,再用异步任务按顺序执行交易扣款。有些第三方代扣服务就是这样设计的
dingyaguang117
乐观锁即可
reeco
实操都是 tcc ,两步提交
love2328
你的想法怕慢 实际不会很慢 并发是同等触发 实际触发时并没有的
xyjincan
love2328
有一次网卡,连点很多下,10 冲了 50
love2328
xyjincan
点的时候 没有置等待 ? 要么场景不够经验 要么坑用户
mrpzx001
用事务不就完事了吗? 怎么都不提事务的?
8355
用户级别并发锁行锁不就可以了吗
改个余额
加订单入库
加资金流水能有几张表
能慢到哪里去啊
你这个下单接口高峰 qps 能有 1000 吗
iseki
如果是扣库存,只要保证别 100 个商品,结果 10000 个请求打到数据库上、也别同一时间点 100 个请求全都在数据库上扣同一个商品,就没什么可担心的,数据库的性能足够。
扣余额就更简单了,限制下不要让一个用户同时发起一堆请求(这本来也该限制吧)
实现上可以用 update cas ,但存在限制不方便时直接 Serializable 性能不一定差( PostgreSQL )
8520ccc
ElmerZhang
update xxx set amount = amount - A where amount = B where amount-A>0
hhhhhh123
vanillacloud
codehz
8520ccc
richangfan
如果这样的话, 同时有俩个 一个扣款 10 块 一个扣款 5 块。 这样只会执行其中的一个余额。 另外一个就不会执行。 我觉得 8 楼的 第三个条件挺好, 但是递归次数 又不好拿捏。
codehz
ElmerZhang
那不如直接 update xxx set amount = amount - A where amount > A (
chenqh
用 redis 锁不就好了吗?
vanillacloud
我觉得在 update 时 「 where 余额 = 扣款前查询的余额」这一步就能规避重复操作的风险,这不能当 standard procedure 吗?
noogel
高并发扣减:
1. 合并请求,在保证事务的前提下,将多个扣款请求合并操作,这样只需要做一次锁操作和写操作。
2. 拆分账户,将热点账户的余额账户拆分成多个子余额账户,以此来降低单个账户扣减操作的并发度。
3. 使用内存数据库扣减,并异步写日志,所有日志结果可以回溯账户余额结果,和内存数据库做对账。
LucasLee92
noogel
1 和 2 的处理对热点账户的处理都只考虑怎么解决记账问题1 的问题在于合并记账后余额不足的怎么处理,可能拆分记有些还能成功2 的问题在于多个账户如何协同管理3 的实现最终还是会碰到热点账户问题,当然效率比起数据库来说要好很多了不清楚是否有相应的成熟业务的解决方案文章能看看
hhhhhh123
ElmerZhang
我理解 第一步和第二步 ,第三部不是特别理解, 为啥只递归一次?
« 上一页
下一页 »