目录
一、概述
本篇着重介绍一下从业务层面的热点账户的经验与实践，修改余额的几种方式见上篇介绍交易系统热点账户问题（一）
二、业务场景分析
可将业务场景划分为如下：
高频入：B端收单账户（结算账户），业务中间账户（业务处理时记录在途资金）
高频扣：B端代扣代发账户（B端支付账户），B端手续费账户（用于做收支分离）
三、业务角度热点账户实践及其特点
1.异步削峰入账
1.适用B端收单账户与业务中间账户，一般B端收单账户资金是在清结算场景时会扣除，不会影响正常的业务，且MQ处理一般也会在毫秒级别完成，高并发时延迟也是在秒级，所以异步入账对商户几乎无感知。
2.异步削峰扣款
适用场景：
1.适用B端代付代发账户以及手续费账户，一般B端高频扣款对相应时间都有一定的要求，且存在余额不足这种不可抗拒的失败因素，所以采用优先判断余额（脏读余额），拒绝掉大部分账户余额不足的请求，其次是异步增加超时以及重试次数的判断，确保请求的有效处理时间保持在一定范围里（超时时间及重试次数可由业务传入）。
3.批量入账（缓冲入账）
适用场景：
1.适用B端收单账户与业务中间账户，一般异步削峰入账可解决大部分高并发问题，但有一些超级B端商户的交易量超级大，可采用该种方式应对。同样，也不会影响该类商户的清结算。
其中，批量入账需新增一种修改余额的方式，一次更新余额，批量插入账户历史
4.子账户（拆分多账户）
适用场景：
1.适用与所有账户的扣款入账。
但是其中存在一些问题解决起来需要多写点代码:
①扣款入账实际操作的是子账户（就是一个单独的账户，只是存了与原本账户之间的关系），主账户不存放余额，余额都是存放在子账户，所以查询余额时，需要做特殊处理（求和子账户）。
②因为分散到多个子账户去处理扣款入账，那么账户的发生后余额就会是个问题（如果不需要发生后余额的话那就很赞了），扣入账产生的账户历史都存放的是子账户的发生后余额（或者不存），要是必须要的话，那就异步计算生成。
③多子账户扣款时会存在子账户余额不足的问题，但实际所有子账户的余额总和可能是充足的，所以需要在余额不足时做子账户资金归集。且若为代付代发的场景，那么对其进行充值时，需要做充值资金拆分，去加到每个子账户中。
四、其他角度方案
单热点账户常见问题及解决方案在上文已经说的差不多了，但是实际场景中并非为单个热点账户。例如，账户基数为1000W，其中高并发账户有1W-5W，在正常扣入账时，这些热点账户在数据库上产生的锁等以及占用的数据库连接都是共享资源，会相互影响，以至于性能很难提升。
分库分表，是个很常见也很好的解决方案，下节单独详说一下。
以上为本人一些粗浅的看法及实践，如有错误或者不恰当处，还望海涵，帮忙指出，也欢迎留言讨论，邮箱地址[email protected]，下次一起讨论一下账户的分库分表实践。
环境：Spring + Mybatis + DB2
欢迎转载，转载请注明出处，谢谢。