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

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

下面将以问答形式分享解决方案:

底层账务优化相关,根据实际业务进行脱敏描述:

前言:现在我们系统有很多商户,顾客会产生订单,其所有父级代理商也会产生分润,商户和父级都可以在自己后台看到对应数据,如果现在某父级下的商家交易很多,那么对应也会产生很多分润订单,需要去累计账户余额


问:在高并发下 这个父级代理商的资金账户频繁的修改,可能会出现修改失败 以及 响应慢的情况,如何处理

答:影子账户:给商家的资金账户做映射,在做资金累加的时候不取真实资金账户,而是去映射表中拿影子账户来操作,这样就能减少高并发下频繁竞争一个资源的问题(分治思想,juc下longAddr也是如此)

问:资金账户频繁修改的问题解决了,但是同一时间还是会有很多分润订单产生,影子账户可以增加并发,但是还是会有失败的情况,如何尽可能去避免

答:WAL+批处理,在产生分润订单时,并不实时向 分润表 写去数据(这张表过大,写入性能会稍低),而是先向一张 记录表 写入分润数据,记录主要信息,然后采用定时任务去进行处理,再定时去清理 记录表

如果量还是大 或 mysql性能还是不足,可以采用MQ来进行削峰,推荐使用RocketMQ事务消息,防止分润订单丢失

问:你这里不管是使用 记录表批处理 还是 采用MQ来进行削峰,最终如果量大取影子表 去进行金额累加,还是可能失败,有没有方法再优化一下?

答:定时批处理 或者 MQ消费后,可以内存中进一步汇总商家数据,再去取影子表,这样可以进一步提升性能,如果某代理商的并发还是高,可以考虑单独给他定制topic 和 消费端[本质是折叠消息]

问:但是站在代理商角度看,我就是想看我到底现在赚了多少钱

答:可以在对应界面上显示:可提现额度,结算中金额(这里提示数据结算中,可能不准确,请稍后查询),我们保证分润订单不丢失,保证可提现金额最终一致性


结语:

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

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

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

相关推荐
小曲程序1 分钟前
vue3 封装request请求
java·前端·typescript·vue
陈王卜19 分钟前
django+boostrap实现发布博客权限控制
java·前端·django
小码的头发丝、19 分钟前
Spring Boot 注解
java·spring boot
java亮小白199724 分钟前
Spring循环依赖如何解决的?
java·后端·spring
飞滕人生TYF30 分钟前
java Queue 详解
java·队列
武子康1 小时前
大数据-230 离线数仓 - ODS层的构建 Hive处理 UDF 与 SerDe 处理 与 当前总结
java·大数据·数据仓库·hive·hadoop·sql·hdfs
武子康1 小时前
大数据-231 离线数仓 - DWS 层、ADS 层的创建 Hive 执行脚本
java·大数据·数据仓库·hive·hadoop·mysql
苏-言1 小时前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
界面开发小八哥1 小时前
更高效的Java 23开发,IntelliJ IDEA助力全面升级
java·开发语言·ide·intellij-idea·开发工具
草莓base1 小时前
【手写一个spring】spring源码的简单实现--容器启动
java·后端·spring