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

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

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

---

        问：在高并发下 这个父级代理商的资金账户频繁的修改，可能会出现修改失败 以及 响应慢的情况，如何处理
        答：影子账户：给商家的资金账户做映射，在做资金累加的时候不取真实资金账户，而是去映射表中拿影子账户来操作，这样就能减少高并发下频繁竞争一个资源的问题（分治思想，juc下longAddr也是如此）
    
        问：资金账户频繁修改的问题解决了，但是同一时间还是会有很多分润订单产生，影子账户可以增加并发，但是还是会有失败的情况，如何尽可能去避免
        答：WAL+批处理，在产生分润订单时，并不实时向 分润表 写去数据(这张表过大，写入性能会稍低)，而是先向一张 记录表 写入分润数据，记录主要信息，然后采用定时任务去进行处理，再定时去清理 记录表
                如果量还是大 或 mysql性能还是不足，可以采用MQ来进行削峰，推荐使用RocketMQ事务消息