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

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

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

---

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

---

结语：

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

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

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