高频交易总延迟？2张表告诉你如何进行热点设计！

Posted 2022-10-23 CSDN资讯

对于银行的技术架构来说，账户体系是核心中的核心。在以往IOE的架构中，银行核心系统每秒可支持万级金融交易，对热点账户的支持仍需一定技巧。在基础技术设备自主研发的当下，如何进行国产化的热点账户设计成为各家银行的关注重点，本文作者通过对热点账户的技术实现进行深入解剖，详述了提升吞吐量的“时空”方案，并以冒烟测试和余额不足测试两个思维实验进行了进一步佐证。

作者 | 区伟洪   责编 | 杨阳

出品 | 《新程序员》编辑部

自2019年我国正式提出发展信创产业，信创相关政策也如雨后春笋般相继出台。在相关政策的影响下，各行各业纷纷出台信创相关政策，力求在新一轮发展潮流中抢得先机。金融信创成为信创落地应用进展最快的领域，其中，核心系统国产化是银行业信创的重要阵地，各家银行目前在如火如荼地攻陷这块阵地。

账户体系是银行核心系统的“中枢神经”，在IBM大型机技术的支持下，全国性大银行的账户体系每秒可支持高达万级的金融交易，中小银行的账户每秒亦可支持成百上千的金融交易。但既然要大力推进银行核心系统国产化，就需要放弃IBM的大型机技术，转向使用基于国产化数据库的设计，这对账户体系的设计形成不小的挑战。要继续支持每秒万级金融交易，就必须让设计更有技巧。

注本文节选自《新程序员·005：开源深度指南&新金融背后的科技力量》，目前已开启预售，欢迎大家扫描上方二维码订阅！

挑战：支持热点账户的高频交易

最大的挑战来自于热点账户，它是账户体系中一种能支持高频交易的账户。热点账户在业务处理上的要求与普通账户几乎没有差别，但在交易频率上的要求比普通账户高，普通账户的交易一般为几天一次乃至几周、几个月一次，而热点账户的出账、入账频率可能达到每秒几百次，甚至上千次。

在电子商城中，商户的交易账户是一种典型的热点账户，目前民众的消费大多是通过线上进行的，一个热门商户的账户可能有每秒数千个出入账记录，分摊到每家银行，至少要求单个银行的账户能支持每秒500个出入账交易。若银行的支持能力低于这个要求，商户就会向更有能力的银行寻求支持，部分金融交易就会分流到其他银行，甚至可能改投其他银行怀抱。

为什么支持热点账户的高频交易有一定难度？可以从金融交易的处理流程说起。如图1所示，金融交易的业务步骤一般为：常规检查、余额检查、余额变更、后置处理。其中，余额检查、余额变更、后置处理是对账户数据有变更操作的，计算机在技术处理上，为了保证交易的原子性、完整性、一致性，防止账务差错，就要加入事务控制。在一般的技术设计中，都是在余额检查前开启事务，在后置处理后提交事务。

图1 普通扣账过程示意图

事实上，一个账户在同一时间只能被一个用户开启事务，事务开始后该用户方能对该账户进行变更操作。其余用户如需操作该账户，就要等待该用户结束事务后，竞争得到开启事务权利的其中一个用户才能操作。未竞争到开启事务权利的用户就要进入新一轮等待。当多个用户并发同时向同一个账户进行转账时，就形同千军万马过独木桥，同一时间只能有一个用户过桥，其余用户需要排队等候。图2演示了这种等候情况。

图2 并发用户等待情况示意图

假如转账操作的平均耗时为n毫秒，用户1、用户2、用户3在0毫秒时同时要转账给同一账户，由于有事务控制，用户1在0毫秒时拿到账户操作权利，在n毫秒时转账结束，实际处理时间为n毫秒；用户2在0毫秒时要等待用户1事务结束，在n毫秒时拿到账户操作权利，在2n毫秒时转账结束，实际处理时间为2n毫秒；用户3在0毫秒时要等待用户1事务结束，在第n毫秒时要等待用户2事务结束，终于在第2n毫秒时拿到账户操作权利，在第3n毫秒时转账结束，实际处理时间为3n毫秒。

由于事务控制，单个热点账户要达到每秒支持500个交易请求，按上面的推导过程，就是要500n小于或等于1000毫秒（一秒等于1000毫秒），需要一次转账操作的时间小于2毫秒。这在普通的交易流程设计下，使用IBM大型机技术作为支持可能勉强达到。而国产化数据库是运行在普通计算机上的软件，支持普通设计下的一次转账通常要耗时几十到200毫秒。这就要采用有技巧的技术设计，保证既能遵守业务要求，又能支持热点账户的高频交易。

思路：提升吞吐量的“时空”方案

提升计算机系统吞吐量（并发量）的办法，归根结底有两个：一是增加“独木桥”的数量或增加“桥”的宽度，让同一时间可以有更多的用户“过桥”；二是减少用户“过桥”的时间，单位时间内能让更多的用户“过桥”。前者是空间方案，后者是时间方案，两者双管齐下效果更佳。

本文的设计在空间方案上尽量将账户的事务控制去掉，让多个用户可以同时执行转账过程的不同阶段操作，增加了“桥”的数量；在时间方案上，将原来部分联机执行的交易步骤改为由计算机系统后台自动延时执行，这样用户联机执行的步骤少了，缩短了“过桥”时间。

分析

在转账的四个步骤中，常规检查、余额检查两个步骤是必须联机执行的。执行常规检查确定交易符合监管合规要求，进行基本的风险控制。同时必须执行余额检查确保账户有足够余额进行转账，避免银行赔钱。

余额变更则可以改为延时执行，有计算机后台将多笔转账金额求和，一次变更账户余额，避免了对该账户开启事务的次数过多。普通方案下，对一个热点账户500次转账需要开启500次事务，延时处理设计下，只需开启1次事务。

后置处理是记录操作日志、交易流水、会计核算记账等操作，这些操作本来就对用户无感，只是银行为了记录交易痕迹，事后核对账务正确性而设计的记录性操作，也可以和余额变更一同改为延时执行。

概述

经过以上分析，热点账户的处理过程可设计为如图3所示。

图3：热点账户联机、延时扣账过程处理示意图

在该设计中，联机步骤的事务控制基本去掉了，当然是指整个过程的长时间事务被去掉。长时间事务的去除相当于增加了“独木桥”的数量或增加了“桥”的宽度，而一些短暂的数据库操作仍存在占用时间很短的事务，但这种小事务不影响“桥”的宽度。

表设计

在银行核心系统原有的表设计基础上增加了《余额占用表》和《延时任务表》，用以辅助去掉长时间事务，以及辅助联机步骤传递交易信息给延时步骤。《余额占用表》的关键字段设计如表1所示。

表1 《余额占用表》的关键字段设计

《延时任务表》的关键字段设计如表2所示。

表2 《延时任务表》的关键字段设计

以上两个表在结构上几乎一样，记录的数据几乎也一样，但不应合并为同一个表。因为《延时任务表》起着降低操作执行时间，减小事务时间长度的作用。

联机步骤

有了上述的知识准备，下面说说整个交易的详细处理过程，首先从联机处理步骤说起。

第一步，常规检查：用户提交转账请求，计算机系统首先执行常规检查，确定交易符合监管合规要求，进行基本的风险控制。如不符合要求则返回错误提示给用户。

第二步，余额检查-1：先开启短事务然后往《余额占用表》插入一笔记录，含流水号、账号、交易金额、会计日期、记录创建时间，并马上结束这次短事务，确保刚插入的数据库记录对其他用户可见。（关键点：事务马上提交。）

第三步，余额检查-2：对《余额占用表》的同账号的、创建时间小于等于本交易创建时间的记录的交易金额求和，如果是正数，则无须检查账户余额，因为不会造成短款（即银行要补钱）；如果是负数，表示要从当前账户余额减去的金额，需要对比账户余额，够扣则继续执行后续步骤，不够扣则删除《余额占用表》本交易的记录并返回余额不足给用户。（关键点：查询条件创建时间小于等于本交易创建时间，另若删除《余额占用表》本交易的记录失败需在延迟步骤中彻底处理。其实不删让延时任务处理也可以，这样更快。）

第四步，生成任务：第三步检查通过表示交易的条件已就绪，其余处理放在延时步骤中即可。那么，往《延时任务表》插入一笔延时任务，含流水号、账号、交易金额、会计日期、《余额占用表》的记录创建时间、状态0等，插入成功则返回交易成功给用户。这次插入操作也是个短事务。（关键点：插入《延时任务表》一笔记录，比更新《余额占用表》中本交易的记录耗时要短得多。）

联机步骤至此结束，步骤不多，且事务时间很短，所以几乎没有瓶颈。

延时步骤

联机步骤执行成功，交易就可以认为成功了，只是交易资金临时放在延时任务表中，没有入账。延时步骤主要处理资金入账及相关后置操作。延时处理步骤是个定时任务，例如1分钟执行一次。下面具体介绍延时步骤每次被触发后的处理过程。

第一步，加载任务：加载《延时任务表》中待处理的账号并去重，针对每个账号，执行以下步骤。

第二步，余额变更：从未处理的账号中选择一个账号进行处理，根据该账号加载《延时任务表》中待处理的任务，区分不同的会计日期，汇总金额更新到账户余额中，处理日终余额。

第三步，后置处理：根据《延时任务表》交易入账时间升序排列，逐行处理排好序的结果集，记录账户的交易流水，进行会计核算记账，记录金融交易操作日志，更新任务状态为已处理。

第四步，循环处理：重复以上第二步、第三步，直至第一步选出的账号处理完毕，然后结束本次处理，等待下一次被触发处理。

实验：冒烟测试&余额不足测试

本文以思维实验的形式，举例对上述方案进行验证，同时，借助所举的思维实验例子加深大家对方案的理解。

冒烟测试（思维实验）

先介绍一个简单的实验，账号为“ACCOUNT1”，初始余额为1000，在一秒内收到4笔扣账交易请求。

经过联机步骤处理后，《余额占用表》和《延时任务表》的记录如下（见表3、表4）。由于流水号为TRX001的处理时间稍长，此时尚未来得及登记入《延时任务表》。

表3 《余额占用表》

表4 《延时任务表》

定时任务触发了一次延时处理，流水号为TRX002、TRX003、TRX004的交易被延时处理，ACCOUNT1的余额被一次性更新为920。《余额占用表》和《延时任务表》的记录如表5、表6所示。

表5 《余额占用表》

表6 《延时任务表》

TRX001的联机步骤在定时任务执行完后处理完成，《余额占用表》和《延时任务表》的记录如表7、表8所示。

表7 《余额占用表》

表8 《延时任务表》

在下一次延时处理前没有交易进入，此次延时处理则按第2点的方式进行了批量处理，但仅处理了TRX001这笔交易。数据库记录的情况显而易见，不再展示。

余额不足测试（思维实验）

账号ACCOUNT1，初始余额为1000，在一秒内收到4笔扣账交易请求，扣账金额分别为300、400、500、600。

第一笔交易TRX001进来，扣账300，执行联机步骤完成后，数据情况如表9、表10所示。

表9 《余额占用表》

表10 《延时任务表》

第二、第三笔交易同时进来，分别扣账400、500，执行联机步骤途中，数据情况如表11、表12所示。

表11 《余额占用表》

表12 《延时任务表》

由于余额检查中TRX001、TRX002、TRX003的扣账金额之和为1200，大于ACCOUNT1的账户余额，TRX002、TRX003的余额占用记录被删除，并返回余额不足错误给用户。由于第2点的TRX002、TRX003余额占用记录被删，此时数据情况与第1点相同。

第四笔交易进来，扣账600，此时没有并发的交易进来，余额检查通过，交易成功，《余额占用表》和《延时任务表》各增加了TRX004的记录，数据不再展示。

其他

请大家参照上述两个思维实验脑补其他情况以验证该设计的完备性。

结语

截至本文完稿时间，本设计已在某银行国产化核心系统实施，并进行了SIT环境压力测试，基本可达成设计目标，相信在生产环境更优的硬件支持下，该方案会有更 佳的表现。

本文仅讨论了热点账户设计的关键逻辑的设计。不同的银行有不同的银行核心系统账户体系设计，还需要结合不同的账户体系设计实现冲正、日切、计息等处理。此外，还需加入技术架构上的单元化、分库分表、分布式事务等与技术栈相关的设计，方能形成完善的可落地的热点账户个性化设计，欢迎就此与笔者讨论。

作者介绍

区伟洪，某银行资深工程师，从业近20年，业务架构上接触过存款、贷款、客户信息等领域，进行过手机银行、柜面渠道等渠道应用研发，技术架构上了解过技术框架、分布式技术、网络安全、反欺诈风控、大数据等方向，擅长数据建模、架构建模并化繁为简，喜欢看电子书，有一套快速阅读方法。

—————— 推荐阅读 ——————

《新程序员·005：开源深度指南&新金融背后的科技力量》特别策划了“开源深度指南”和“新金融背后的科技力量”两大专题。邀请到当今开源世界的先锋人物，包括Python之父Guido van Rossum，mysql之父Michael "Monty" Widenius，Apache之父、OpenSSF开源安全基金会总经理Brian Behlendorf，MongoDB CTO Mark Porter、凝思董事长宫敏、Linux内核守护者吴峰光等，更有国内外开源基金会、知名企业代表，从开源安全合规、企业内部开源、开源技术创新、开源行业落地等多方面，为开源背后的开发者、企业、开源组织及开源社区提供更清晰的开源生态建设与升级版开源发展全景式图鉴。

而在金融专题中，来自中国工商银行、邮政储蓄、中信银行、广发银行、中国人民银行、平安科技、微众银行、蚂蚁集团等十数家传统金融机构和头部金融科技公司的技术专家为我们带来了关于各类新一代颠覆性技术的深入讨论和案例分析。深入解答开发者应该如何更好融入金融产业，以及金融科技的人才培养之道，真正做好金融科技的技术创新和数字化转型。

欢迎大家扫描订阅《新程序员》