概要：1.汇总明细记账(透支)、2.缓冲入账(透支)、3.子账户拆分(麻烦)、4.缓存实时记账,异步入库（金额混乱并发）
ps：注意本文是内部账户，和上一篇垫付无关
账户冲扣要满足：更新账户余额。明细表中更新前后余额，操作金额
为什么做热点账户设计？
记账过程两部分：记账凭证，更新账户余额。处理时，锁账户，产生性能瓶颈。下面是解决方案
一、汇总明细记账
定时(如半个小时)将账务明细sum出总金额，入到指定账户。不能实时入账，有透支地风险
二、缓冲入账
将同步记账请求异步，削峰填谷。账务系统阈值100笔/s，24小时不间断(一天86400000笔)。高峰期，200笔/s。先返回结果，丢队列中，并发不大时慢慢消化。
缺点：扛不住暴增，有透支风险
三、子账户拆分
创建 与热点账户对应的结构相同 多个影子账户，设置为隐藏，余额分散至各个影子账户。
请求hash分配（具体hash函数会有更多方案）选影子账户记账，分散了账务热点。
缺点：子账户余额不足，但总余额够，影响成功率。
四、缓存实时记账,异步入库
redis做数据前置处理：db热点账户金额同步redis，流水定时刷到业务表。缓存衍生金额混乱并发问题：
redis初始金额100，1)线程1减60，余额40,记录流水表等待异步入账。 2)线程2减60时，余额-20必须反向操作。 3)线程2还没反向操作时，线程3充值-20+100=80
五、实际操作（1汇总记账 和 4缓存入账）
1、设计前提：不允许金额错误
1)不允许多扣，少扣。2)准确记录流水表中期初余额，期末余额，操作金额等情况
2、步骤
1）新增 延迟入账【流水表】，入/出账数据先入【流水表】,定时任务将【流水表】入账和出账数据同步 账户和账户明细表 ，并且负责入账数据 缓存同步
2）新增redis SortedSet（有序集合）key为【hotspot_account】缓存操作记录：score为当前账户操作时间【新盖旧】,member账户ID
3）新增redis SortedSet（有序集合） key为hotspot_account_currentbalance 缓存余额。score当前账户可用余额，新操作前要将db数据同步到hotspot_account_currentbalance中。member为账户ID
(1)当账户金额充值新增时:
1:记录redis操作记录【hotspot_account】：红色部分，当账户110000056666660010入账时,插入或更新数据，member=110000056666660010,score为当前时间戳（秒）。
ps:操作指令【ZINCRBY key increment member】，当key不存在，或member不是 key 的成员时， ZINCRBY key increment member 等同于 ZADD key increment member 。
2：新增【流水表】，设置入账状态为未入账
(2)当账户金额扣减时:
1:同金额充值,先记录redis操作记录【hotspot_account】
2:直接对缓存hotspot_account_currentbalance对应的金额进行扣减
1）扣完>0成功，计入流水表(未入账)
3:定时任务：将流水表数据更新到 账户表 和 流水明细表，设置流水表数据已入账，同时将新入账数据流水到更新hotspot_account_currentbalance中可用账户余额，让扣减操作继续。以下操作流程：
极端情况：超扣，定时任务发现当前缓存余额<0，会再从流水表 重查db数据入账，部分线程没入账到db，就是说线程1扣redis成功，但没insert到流水表，这时线程2扣redis为负，定时任务发现。
解法：不该直接同步余额，应加锁扣，但加锁复杂性，采用简单的办法，扣减redis和mysql都瞬时，直接sleep 5 s即可，足够发生full gc等其他耗时
5.升级服务硬件,对CPU内存等进行升级
总结：几种方案的对比
1：汇总明细入账：实际业务是【频繁出账，低频入账】，不可取。
2：缓冲入账：需动态判断流量低峰高峰，维护请求队列，有账户透支地风险，异步请求中结果不可控。
3：子账户拆分：可能影响成功率，子账户扣款和入账要做到金额相对平均比较复杂。
4：内存数据库实时地处理记账,异步入库 ok
5：增加硬件处理能力CPU.内存：备选方案,无法从根本上解决
https://www.jianshu.com/p/47bf0857342e
