关于刚才热点帐户的问题，有几个方案可以讨论

1.并发度控制

同一时刻，对同一账户修改的请求数越多，这个账户的所等待问题就越严重，所谓并发度控制就是要控制同一时刻对热点账户请求的数量，可以通过控制上游支付系统并发请求数据或者账务系统处理的并发请求数来实现。

　　这一方案的缺点是对业务是有损的，当热点账户出现的时候，支付或者账务处理失败率会增加，用户的体验会变差，较大的银行或者第三方支付公司用地比较少。

2.汇总明细记账

实时的交易全部是insert账务明细（insert的开销很小，能够支持高并发。如果基于分布式部署，insert的并发容量理论上可以无限大），然后定时(比如每半个小时)将之前半个小时内的账务明细sum出一个结算总金额，一笔入账结算到指定账户。

　　这个方案的缺点就是：交易不能实时入账，其实如果控制好定时汇总入账的频度，比如分钟级，用户也是可以接受的。这种方式对收单类业务（账户加钱）非常实用，但是对支出类业务（账户减钱）类来说，有账户透支地风险。

3.缓冲入账

将实时同步的记账请求进行异步化，以达到记账实时性和系统稳定性之间平衡的记账手段，这就是”削峰填谷“。

　　详细地讲，假如账务系统对同一个账户的处理阈值为100笔/s，24小时不间断服务(一天能处理86400000笔)。当业务高峰期来临的时候，热点账务的请求数会达到200笔/s。当账户的交易低于100笔/秒的时候，账务系统几乎还是实时地处理了记账请求，而当交易大于100笔/秒的时候，账务系统先返回结果，把账务处理丢到可靠的处理队列中，等并发量不大的时候慢慢消化，对用户来说感受到的体验还是很快就记账成功了。

　　这个方案是有个前提是：热点账户在某几个高峰时间点需要缓冲记账来削峰填谷，并且能在日间填完。一旦账户的日间交易量暴增，导致日间队列根本来不及消化，整个队列越来越长，那就不存在谷可以填，这时候肯定会带来用户大量的投诉。另外这种方案对支出类业务（账户减钱）来讲，也会有账户透支地风险。

4.热点账户锁分散

具体来讲就是创建与热点账户对应的多个影子账户，所述影子账户与所述账户的数据结构相同，将所述影子账户设置为隐藏，并将所述账户的余额分散至各个影子账户。当账务系统接收到账务请求的时候，通过前置进行hash分配（具体的hash函数会有更多方案）选择影子账户进行记账，这样就将原来对一个账户的请求分散到多个影子账户中，分散了账务热点。

　　这个方案也有缺点：通过算法选择的影子账户扣款，影子账户的余额可能是不足的，但账户的总余额是够的，这样可能影响账务处理的成功率。

5.提高服务锁并发能力

提高单台数据库服务器处理能力（I/O,CPU,memory）或者选取内存数据库实时地处理记账请求，然后异步地存储到可靠数据库上。