高并发场景下底层账务优化方案

发布时间:2024年01月14日

????????在秒杀等场景中,经常会需要对库存、商家冻结资金做一些修改,而并发一旦上来后会导致这个修改动作频繁超时及失败,那么如何处理呢?

下面将以问答形式分享解决方案:
????????底层账务优化相关,根据实际业务进行脱敏描述:
????????前言:现在我们系统有很多商户,顾客会产生订单,其所有父级代理商也会产生分润,商户和父级都可以在自己后台看到对应数据,如果现在某父级下的商家交易很多,那么对应也会产生很多分润订单,需要去累计账户余额


????????问:在高并发下 这个父级代理商的资金账户频繁的修改,可能会出现修改失败 以及 响应慢的情况,如何处理
????????答:影子账户:给商家的资金账户做映射,在做资金累加的时候不取真实资金账户,而是去映射表中拿影子账户来操作,这样就能减少高并发下频繁竞争一个资源的问题(分治思想,juc下longAddr也是如此)
?? ?
????????问:资金账户频繁修改的问题解决了,但是同一时间还是会有很多分润订单产生,影子账户可以增加并发,但是还是会有失败的情况,如何尽可能去避免
????????答:WAL+批处理,在产生分润订单时,并不实时向 分润表 写去数据(这张表过大,写入性能会稍低),而是先向一张 记录表 写入分润数据,记录主要信息,然后采用定时任务去进行处理,再定时去清理 记录表
?? ??? ?????????如果量还是大 或 mysql性能还是不足,可以采用MQ来进行削峰,推荐使用RocketMQ事务消息,防止分润订单丢失
?? ?
????????问:你这里不管是使用 记录表批处理 还是 采用MQ来进行削峰,最终如果量大取影子表 去进行金额累加,还是可能失败,有没有方法再优化一下?
????????答:定时批处理 或者 MQ消费后,可以内存中进一步汇总商家数据,再去取影子表,这样可以进一步提升性能,如果某代理商的并发还是高,可以考虑单独给他定制topic 和 消费端[本质是折叠消息]
?? ?
????????问:但是站在代理商角度看,我就是想看我到底现在赚了多少钱
????????答:可以在对应界面上显示:可提现额度,结算中金额(这里提示数据结算中,可能不准确,请稍后查询),我们保证分润订单不丢失,保证可提现金额最终一致性


结语:

? ? ? ? 上述主要的思路是:影子表分治、WAL、定时批处理、请求折叠、MQ削峰

? ? ? ? 此思路不局限于解决上述场景,其实对于秒杀扣减库存这样对资源有竞争的场景都适用

? ? ? ? 需要结合具体的业务采用最合适的方案,技术无银弹

文章来源:https://blog.csdn.net/weixin_44700876/article/details/135478606
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。