[FinTech]不可能的网联之一：支持每秒18万笔？！

来源: ​文 | 财新特约作者 张烜鸣   

编者按：专门为第三方支付机构服务的清算平台——网联，这一中国独有的金融基础设施，筹建之初曾备受质疑：在国内两家互联网支付巨头已经直联超过200家商业银行后，央行重新构建网联这样的基础性平台，是“不可能”的任务目前，网联已试运行半年有余，财付通等主要支付机构陆续启动业务切量；最终将称为一头对接115家持牌非银行第三方支付机构，一头对接近300家商业银行。在即将来临的2017年“双11”，网联将迎来首次海量支付的考验，支付宝也将按照约定把50%的交易量切到网联平台。而网联会不会在天量交易面前”瘫痪”？

网联又称“非银行支付机构网络支付清算平台”，是为国内所有非银行支付机构搭建的一个共有的交易转接以及清算的平台。可能有人会担心网联模式下会不会对支付性能有影响？特别是即将来临的2017年“双11，还能不能开启疯狂剁手模式？七夕节早上5点20分女神能否准时收到微信红包？

答案当然是肯定的。面对高并发、低延时的支付场景需求，网联采用高性能的分布式架构，完全能支撑住大家愉快地买买买和节日表白。

先以超市购物的例子来说明网联清算模式下的整个支付清算业务流程：

• 小明在超市买了1000块钱的商品，用微信支付时选择使用绑定的招商银行卡付款；

• 财付通收到小明的请求后，向网联平台发起一笔协议支付交易；

• 网联平台将交易信息存在数据库里，并将请求转发至招行，招行在小明账户扣掉1000块钱，网联收到招行扣款成功的通知后，会给财付通反馈支付成功的回执，同时通知工行(财付通备付金行)给财付通工行账户增加1000块钱。

• 最后，财付通将支付结果通知小明，小明带走商品。

小明需要等待支付结果才能完成交易，因此要求整个支付链路具备低延迟的特点，网联交易转接的处理时间设计为秒级响应。

这种场景，在生活中比比皆是。据数据显示2016年“双11，支付宝的支付峰值达到12万笔／秒，预计2017年“双11”会达到20万笔/秒的支付峰值。根据历史数据推算60%的交易涉及银行账户的网络支付请求，即会有12万笔/秒的支付请求需要转接至网联平台；因此，网联平台的设计目标是支持12万笔/秒的平稳实时转接请求的能力，同时考虑容灾要求，平台满配峰值支持18万笔/秒。　

“三地六中心”支撑

为支撑这样的高并发需求，网联必须考虑异地容灾，多点多活，容忍城市级灾难的机房建设。

业界传统的做法是建设“两地三中心”，而“两地三中心”架构一般只有一个中心对外提供服务，另外一个中心为数据备份（并不对外提供服务），不能满足平台的容灾多活要求。网联采用了“三地六中心”的系统架构，每个机房支持2万笔/秒，峰值支持3万笔/秒，三个城市六个机房同构设计，同时对外提供服务且互为备份。任何一个机房或一个城市发生重大故障，其他机房可以继续提供12万笔/秒的平稳运行服务。

每个机房需要支持3万笔/秒的交易转发峰值。传统的集中式架构最大特点就是将所有的数据都集中存储于中心节点上，并且整个系统的业务单元都集中部署在这个中心节点上，系统所有功能都依靠大型高端设备来提供处理能力，因此集中式架构在单台设备发生故障后影响范围比较大。而分布式架构在分散的结构部署下，单台设备故障导致的运行风险相对较小。

基于分布式架构在互联网企业中的多年成功运行，网联决定采用分布式架构来支持单机房3万笔/秒的处理能力。应用服务通过分布式部署，来减少单台服务器的压力，将3万笔/秒的处理能力分布到上百台云服务器上处理，每台云服务器来分流处理交易请求。

此外，高并发的转接请求和海量数据存储会成为单数据库服务器的瓶颈，会对系统的稳定性和性能造成极大的问题。为解决该问题，网联在数据库上采用了分库分表的分布式数据架构。数据库的分库分表方案可以轻松的将计算、存储、I/O并行分发到多台服务器上，充分利用多台服务器的处理能力，降低了单点服务器的负载并提高了数据库操作效率，提升了整个系统的性能。在技术选型上，网联采用成熟的分库分表基础组件，每个机房部署N个数据库实例，因此每台数据库服务器只需每秒处理3万/N笔的并发请求。此外，网联机房的网络采用多条高速链路互联，实现超高速带宽，也给高并发数据量请求提供了保障。

网联通过“三地六中心”部署，以及单机房分布式服务架构和分布式数据库架构的方式完成了对18万笔/秒的实时交易转接。

分批次清分对账

在网联交易转接模式下，小明支付成功后获得了自己的商品，但是招行和工行之间还没有完成最终资金清偿，网联会对所有交易信息进行清分轧差，清分轧差数据为招商银行-1000，财付通备付金工行账户+1000，网联会生成清算指令并提交中国人民银行大额支付系统，由大额支付支付系统完成各家银行机构资金的统一清算。

但是，网联单日交易规模达数十亿笔，且数据分布在多地六个处理中心，面对如此海量的数据，如何在确保结果准确的前提下提升清算实效？且更要确保证结果的正确？

为了减轻数据集中处理带来的延迟和网络带宽的消耗，网联对数据分批次进行清分，并按场次将轧差净额提交人行大额进行清算。即将交易按照时间片进行切分，每一个分片称作一个交易批次，在批次时间切换后，对批次数据进行清分处理。

有别于传统系统日终集中处理模式，尽量将数据的处理分散开，避免集中处理造成的性能瓶颈和系统压力，同时针对本IDC的交易数据均在本地完成清分处理，只将清分结果通过跨城网络进行上报集中处理平台。集中处理平台作为大脑，对清分的流程进行编排，在预定的清算时点，系统会对尚未清算且已完成IDC级数据汇总的批次清分数据进行集中轧差，形成用于提交人行大额支付系统进行清算的净额数据，进而完成资金的最终清偿。

完成净额数据的最终清偿，参与机构和银行需要交易的最终凭证，即各自的交易流水文件（包括对账汇总流水及交易明细）。据估计峰值为每个批次6.48亿笔原始数据，按机构和收付款行拆分后数据量变为三倍，要求每个批次结束后2小时内提供对账文件。

同时网联是“三地六中心”的分布式架构，交易信息分布化，系统设计从以下几个方面解决了分布式海量数据的及时对账问题：按时间维度分批对账，平台对交易按照一定的时间间隔进行切片，一天会切成多个交易批次，每个批次作为一个独立的对账处理过程。

与传统的集中式日切处理模式相比，多批次对账提高了对账效率，避免了大批量数据集中处理的压力。按空间维度多点对账，交易数据分布在6个机房，对账平台直接在每个机房进行本地计算、生成明细文件、计算本地汇总数据。明细文件保存在当前机房，汇总文件上报集中处理平台。即将整体逻辑按照纵向和横向进行多维度的拆分，通过最大化的并行处理提升处理效率；多点对账同时平均分配了数据量，避免了单点大数据量的压力。最后，在保证数据源完整性、对账性能高效性的同时，通过出错自动重试的流程设计，保证对账文件的数据完整性。

在这种网联清算模式下的支付业务中，小明完成了实时交易，支付机构、付款行和收款行完成了各自的最终清账和对账文件回执，在千千万万这样的场景中，网联通过分布式高性能的架构，支持了高并发下的实时交易转接处理以及批量交易的清算对账。

作者供职于网联　　

（编辑：杨少康）

来源: ​文 | 财新特约作者 张烜鸣

爱财经