热点账户高并发记账方案

热点账户带来的其实是性能问题，多笔交易需要给同一账户记账时，会产生一笔交易等待前一笔交易记账完成才能接着记账的问题，这样就会产生事务等待问题。
方案：
1、汇总明细记账（适用于不需要实时更新余额，且主要是增加账户余额的场景）
数据库插入数据是可以支持非常高并发，可能达到3.2w/s，所以插入流水不是热点账户瓶颈所在，而是余额更新。
2、缓冲记账，消息队列（）
3、子账户拆分
实际根据实际业务使用场景，按照金额变动方向，分成加频账户（余额增加频繁）、减频账户（余额扣减频繁）、双频账户（余额增加扣减均频繁）
三种账户的处理方式各不一样：
• 加频账户处理：准实时更新余额。先将金额变动插入临时表中，由定时任务按照一定频率汇总发生额，并更新账户余额，而后删除临时记录。当加频账户减钱余额不足时，主动去汇总发生额。这里需要考虑主动汇总发生额和定时任务处理的并发情况，在该定时任务执行时设置redis锁，防止并发，主动汇总时会去判断这个redis锁是否存在，如存在证明定时任务正在执行，无需主动汇总，可能是真的余额不足。主动汇总同样会设置redis锁，定时任务同样会判断。
• 减频账户处理：将减频账户拆分多个子账户，减频子账户设置金额报警，如果某个减频子账户余额不足触发报警，会对该子账户做资金归集，将其他子账户余额归集到该子账户（每个子账户设置可归集金额限制）。如在交易过程中发现该子账户余额不足，转向使用其他子账户记账。由于拆分子账户，余额查询时需要汇总各个子账户余额返回；记录主账户流水需要记账后余额，这里需要异步计算汇总。当减频账户加钱时，需要平均分配入账到不同的子账户。
• 双频账户处理：将双频账户拆分多个子账户。加钱时，准实时更新余额，先将子账户金额变动插入临时表中，由定时任务按一定频率汇总发生额，将汇总的发生额更新进对应的子账户，并删除金额变动记录；减钱按照之前减频账户的逻辑执行。
4、Redis+MySQL
选用内存数据库实时处理记账请求，然后异步更新到关系型数据库上。