热点账户问题和常用解决方案【中】

摘要：通常伪同步方案采用三件套日志校验位广播消息来完成一次完整的请求流程图一般如下请求阶段同步请求调用，核心要素追加写入日志，变更校验位，完成同步调用此处追加写保证了快速写入，校验位来保证数据的最终写入成功。

话接上回，上篇阐述了什么是热点账户，基本财务账户如何设计，幂等健和链式设计！本篇将针对热点账户在实践中引发的问题，梳理和拆解业务流，分析问题点，提出七种常用解决方案。

上线初期数据量较小，运行正常！
一次大促后，账户流水的总数目接近亿级别，初现性能问题：系统整体的qps也就10+，但热点账户写入失败率偏高，并且随数据量增加失败率逐步升高；整个账户系统全靠上游有redo标识位不断重试，才能保证最终写入成功!

哈哈，作为一名拥有三年工作经验的老码农，面对问题，要做的第一件事，就是静，抽根烟静静，准备开搞！

拿到问题，抽根烟静一下之后，分析问题需要三步：梳理数据流，拆解过程，定位问题点。先对财务账户更新的数据流进行拆解

链式锁后的基本账户操作过程，分为如下五阶段

请求阶段：账户操作请求。

查询阶段：查询当前账户信息。主要获取当前链，资金数据等！

计算阶段：对链和操作的资金进行计算，判定资金操作合规，同时保证幂等和并发！

写入阶段：事务同步写入流水和余额

响应阶段：告知上游回调

梳理数据流后，接下来分析每个阶段可能引发的问题。按照优先级，先分析业务问题区域（读取阶段，计算阶段，写入阶段），通常问题会出现在业务阶段；之后，再分析框架问题区域（请求阶段和回调阶段），该区域出现问题的情况偏小，但是一旦出现问题，就是比较有意思^_^！

读取阶段，计算阶段，写入阶段三个阶段是具体的业务操作，从并发和耗时两个角度来分析下可能的问题点

耗时分为三块

查询耗时：RDS拥有亿级别数据量，查询未中primary，但命中索引，业务数据体并未完全在索引中，因此访问数据走index match；数据主键聚簇，唯一健索引查询获取数据，page极难命中cache，也不会命中磁盘电梯算法优化！结合实际情况，查询耗时在10-100ms级别

写入耗时：insert 包含了自增，理论上在数据落盘是追加写，即使uniq_key去创建索引的情况下，耗时在ms级

过程耗时：长连接情况下，init conn时间基本可以忽略，但是读写两次往返数据库的链路时间还是需要考虑，整体预估在1-2ms之间

从整体上看，预估该阶段的耗时在10-100+ms，从实际失败率来看也基本一致！

天级QPS：当时分析天级几十万单，天级QPS不到10，不高！

瞬间QPS：每个订单拆解到资金流后，会同时操作多次热点账户，瞬间qps相对很高，理论qps就可能达到语言上限，由于上游链路限流1024，按照10级别操作拆分，理论上满池QPS在万级别。考虑实际单量，瞬间QPS=单量(10)*拆解量(10)，实际的满额预估QPS可能到100+ ！

按照上面分析，在瞬时QPS达到10+的情况下，热点账户整体延时在10-100+ms，由于DB在写入uniq_key保证链点唯一，所以出现并发写入失败也在情理之中；并且随着数据量的提升，读取延时增加，写入失败率会继续增加。

请求阶段做为入口，一般也分为三个小阶段

webserver接收请求

框架加载和路由

基础校验

请求阶段核心耗时一般存在于框架加载和路由，高并发场景webserver和upstream之间的调用也是一个可能出问题点！当时财务系统，采用欢总封装的go-thrift，并且其他模块并未出现请求阶段问题，所以并未对这个阶段的latency和并发做一个衡量，重点分析了业务模块！

通过上面分析，目前问题的痛点是并发读取热点账户数据高延时引发写入失败，提升读性能成为了关键

读性能提升有两个基本思路：读的时效快和读的次数少

针对上面两个基本思路，结合财务账户情况提出了五种提升读性能的解决方案

【读快】持久化last record：不从全量数据里面读，抽离子账户的最新信息，持久化到多带带的表中或者内存中，降低整体数据量，提升了读性能。缺点是要保证持久化信息的准确性，引入事务写。

【读快】纵向切分-时间分库分表：按照时间进行纵向切分，降低查询范围内的数据量，提升读性能。缺点是跨时间读不友好，开发量也不小

【读快】纵向切分-归档：历史数据归档是实现相对简单，跨时间读也比较友好，随着数据量的提升，也是必须要做，之后会详细介绍归档方案和选型。

【读快】横向切分-业务分库分表：按照账户类型或者城市分库分表，可以优化读写数据量，同时，跨表读负担也会较小。但对于热点账户或者热点城市，依然聚簇，效果不是很明显。同时，再次对热点账户进行横向分库分表也是极度不推荐，引入的极高的读写成本均。

【读少】阶段快照：一定量或者一定时间内的数据，持久化一次。优势是极大的降低读写次数；缺点是需要复杂的逻辑来保证undo操作和数据一致性！

五种解决方案各有千秋，作为一个初期的财务系统推荐采用持久化last record和数据归档来保证写入读性能和整体读的数据量。如果系统发展到了中期，推荐按照时间分库分表。如果发展到了双11或者春晚某些极端场景，牺牲掉部分准确性，采用阶段快照也是可以的。

存在计算阶段造成的最大影响也就是引起了两次数据传输，通常是不可避免的，但是如果真的是要进行提升有一种方案通用方案

DB计算：通过存储计算，转嫁计算成本给DB，减少一次链路请求。但不太推荐，复杂的sql往往有坑，insert computer from select 还会造成大面积的数据隔离，很容易引起死锁。

请求阶段一般有三种形式：同步调用，异步调用和伪同步调用！
前两种调用非常常见：同步爆池的情况，一般采用限流来降压，采用漏桶，令牌桶等等策略；异步调用通常采用消息队列来削峰填谷；这里重点阐述对于支付和财务系统在请求阶段经常采用的伪同步的方式

伪同步流量较早出现在innodb，leveldb等存储引擎为了利用追加写提升写入性能，采用类WAL日志来持久化数据。通常伪同步方案采用三件套：WAL日志+校验位+广播消息来完成一次完整的请求！流程图一般如下

请求阶段：同步请求调用，核心要素追加写入wal日志，变更校验位，完成同步调用！此处追加写保证了快速写入，校验位来保证数据的最终写入成功。图中1，2

异步阶段：通过读取wal日志的核心数据，进行复杂事务处理，如果成功进入下一阶段；如果失败，没问题，通过外部trigger来触发redo操作！如果多次redo依然失败，那么通过undo来回滚数据。

回调阶段：如果成功，更改校验位，同时发布成功广播消息，关注结果和时效性的模块，可以获取最终成功的标识！如果undo回滚数据，则发布失败广播消息，告知结果失败！

在伪同步的模式下指标衡量：

QPS：伪同步模式，采用WAL核心要素追加写，所以写性能可以极大提升，进而满额QPS相对直接同步调用也大量提升

时效性：伪同步并非完全同步，所以结果需要监听回调。对于结果强一致的请求，必须监听回调，确保一致，时效性降低；对于弱一致可以认为同步回调即成功，时效性提升。

失败率：操作知识核心要素追加写入，真正的操作通过异步保证，整体成功率提升！

对于资金处理过程，大量采用伪同步的请求方式来保证快速写入和最终一致性。

总的来说，归结了七种优化方式（哈哈，上篇写的八种优化，当时总结的，现在愣是想不到还有啥了^_^）。其中请求和回调的伪同步方式，是在架构层面优化，这个在多数的财务系统和财务系统的内部数据流中都会用到；而读写和计算阶段的优化，可以跟进实际业务情况进行选型处理。

面对各种优化方案，需要结合实际情况做出取舍，有的是长期方案，有的是快速方案，但一定需要想清楚了再开搞，过程中有一个对小拽之后影响很大的事故，引以为戒。

翻车过程：当时觉的读->计算->写这个过程，两次读DB操作，下沉计算过程到DB后，通过DB计算，可以减少一次数据库请求。于是合并了一个大SQL，也就是所谓的insert ( field computer from select)，觉的写了个狂赚酷炫吊炸天的SQL，一上线，库锁死了！幸好有前置的redo flag，全量redo数据恢复，要不然估计直接祭天了！

对于这个复杂大SQL事故，小拽总结了三个方面

莫炫技：没啥好说的，解决问题的成就感要远大于炫技！
简单设计：简单的设计通常意味着可依赖；复杂的设计要尽可能的拆解，想清楚，队友都理解不了的设计，那就别上线了，可能真的需要再思考拆解下
尊重线上：核心服务基本上线流程一定要遵守，测试，监控和回滚方案缺一不可

本篇主要针对热点账户问题提出了七种常用的解决方案，下篇将继续引申探索下，各种解决方案在不规则高并发场景，例如双十一，微博热点事件中如何套用

预知后事如何，下回再聊！

【转载请注明：热点账户问题和常用解决方案【中】 | 靠谱崔小拽 】