问题：
现在直播平台很火，有一个这样的场景：几万个粉丝向网红撒钱，粉丝点击按钮，钱不断减少，网红钱不断增加。如何设计这一块呢？如果直接存库，可能会把库干趴下。
讨论：
A：这个涉及到第三方交易，不可能是加减法那么简单
B：钱的加减请求丢到MQ里面缓存，然后一千个加减纪录作为一笔，累计网红和粉丝的钱数加减，然后更新一次数据库，这样一千个粉丝撒钱只需要更新一次库，减少对库的IO，至于单条账单纪录可以写日志慢慢解析入库，因为纪录要求的实时性不高。
B：然后性能上堆机器，加几个节点差不多了
A：意思是批处理代替单处理，减少调用远端接口的次数
A：批量处理固然效率高，但是并不灵活，应该还要加上时效性。如果10个小时都达不到一千次，难道还要等到10个小时之后才发起一次连接远端接口。
A：人家交易早就取消了
B：这个场景不是面对面交易，粉丝撒钱都是以礼物的形式送的，而不是每一次请求都要完成一次银行账户的交易，所以后台只需要统计，这样批处理是很快的。
A：这类交易不适合用批量处理，万一中间有一笔有异常就很麻烦。
B：每一笔都会纪录日志，而且统计只是为了给实时用户提供热点数据，网红要知道谁给自己撒了钱，这里的过程不会直接涉及到银行交易，不会因为某一笔异常导致回滚这样的操作，一般不会出问题，只是单纯地礼物累加
A：关键是看人家远端接口是否支持批量交易啊
B：没有批量交易，这里的批量只是批量统计，然后交易可以从日志中解析，然后一条一条完成，首先把实时数据提供出去。
A：我觉得瓶颈应该是能否保证并发调用远端接口的效率，写回本地日志完全可以异步慢慢写，至于实时显示给用户的可以不用实时统计，用一个变量做加减就好了。
A：加减比较简单，但要考虑并发安全，这个变量最终肯定要固话到库里，或者保存和库里的一致
A：如果是调用第三方的交易平台，没有回滚之说法吧，交易不在本地
A：除了要考虑并发量，还要考虑的应该是要及时把信息显示给用户，肯定不能等把交易成功的响应数据都写到库里了再统计出来显示，那样太慢了，所以我觉得应该尽量避免频繁读数据库，实时数据可以都在内存里，后面再同步固化到库里
B：所以你们说了那么多 不就是在论证我的方案吗。。 考虑并发所以才会用mq做缓存 并且足够可靠 还有 直播这个场景你们确定了解吗 一般是先在账户里充值了之后 撒钱只扣账户里的钱 或者支付成功之后才会发起一次撒钱的请求 并不是在你发起请求之后 在我说的统计批处理上做交易类的业务 做的批量统计就是为了及时返回给用户他们要看到的数据 写到日志里也是为了押后处理
A：充值的话用的就是虚拟货币了，不能算实时交易，本人不搞电商，有搞电商的大侠出来给大家分享一下高并发交易吧
A：不涉及第三方的交易，就相对简单得多，交易都只是在本地做加减而已，所有用户充进来的钱都已经到商家口袋里了，用户手上的都只是一堆数字，只有提现才涉及真正的货币交易
A：那些什么资金管理系统，其实真正的银行账户就只有管理者手上的一两个，其它上百万上千万客户的账号都只是一个个虚拟账号，如果允许客户内部交易，那根本不需要经过银行，仅仅是内部虚拟账号的金额加减，再怎么转来转去，只要钱不出银行账户就都还在管理者手上
我只是觉得这个思路很好，问题探讨才能完美，如果侵犯当事人的权益，可以私我删除。谢谢！