1. 介绍：
存在问题：
- 账务系统双十一44wtps，单账户记账仅30tps。
原因：
- 通过悲观锁保证记账的准确性和连续性。加锁却导致单账号的并发处理能力下降，俗称账户热点。
- 热点账户广泛存在于大商户收单，代扣，营销、出资等场景，是行业普遍存在的技术问题。
2. 解决方案
2.1 xx解决方案：
2.1.1 缓存方案（削峰填谷）
- 针对热点账户，将记账请求放入缓存队列，做异步处理。
存在问题：
- 当针对某账户的请求过多时，单点的缓存队列存在容量瓶颈。
优化：
- 例如收款方是热点账户，将缓存明细置于付款方，异步执行记账操作。
2.1.2 缓存方案问题
- 用户体验：大商户余额分钟级延迟，很多业务需要商家提前报备申请。
- 资金安全：流出类记账延迟，会容易造成透支资损，且该行为属于垫资行为，支付宝不具备垫资资质，存在监管风险。
- 系统稳定：瞬时的大量数据库加锁操作容易影响数据库稳定。
2.2 行业解决方案
- 异步记账：（银行采用）存在上述问题
- 子账户拆分：子账户拆分，余额调拨业务逻辑复杂，存在余额碎片等问题。
- 流程保障：针对大商户，为了解决提前报备申请影响用户体验、流出透支造成资损等问题，在开户时直接设置走缓存方案，并签署法透追款合同。但也解决不了根本问题，只是一种妥协性的方案
3. 热点瓶颈分析
- 热点产生的主要原因在于加锁，加锁的时长决定了热点的性能。
加锁时长主要由两部分构成：
- 业务逻辑处理过程，多个sql，查询，判断，计算，更新，落表等业务逻辑处理，会引发应用与存储的网络交互。
- sql实现，关系型事务引擎，为保证事务的ACID和减少磁盘读写，会写很多事务日志，每次都存在磁盘io，例如mysql会写redo、undo、bin log。
4. 优化方案
4.1 方案分析
- 减少应用与存储的网络交互，减少磁盘io
4.2 方案说明
- 将记账逻辑与存储层合并，下沉存储层处理，减少应用与存储的交互，减少网络交互开销。
- 存储层日志合并，一次记账仅记录一次事务日志，减少磁盘io；
5 具体实现方案
5.1 计算存储设计
数据存储分为三层：
第一层：api层，类似于传统数据库的sql接受层
第二层：账务的逻辑处理
第三层：存储层，包含内存存储和硬盘存储
5.2 应用交互方案介绍
- 引入Maxwell（高性能KV数据库），支持业务逻辑下沉，并能实现网络，存储IO的优化。
- Maxwell定位于高频记账器，解决热点账户问题。普通账号仍由OB处理；热点账号OB仅记录记账明细，做容灾使用。
- 通过xts保证OB和Maxwell的一致性。
5.3 Maxwell锁实现
- 除了上述通过减少锁持有时长的优化，还在锁本身的机制上做了优化。
- 锁实现并不是采用传统的方式，在加锁数据行上打标，而是通过将指定的节点绑定到一个特定的cpu上，这样该节点的记账请求都会在同一个cpu上进行处理，再加上cpu本身的串行处理机制，这样就可以保证同一个账号的所有记账请求都是一个一个排队并且顺序执行的。
