基于SP/MC网络模型的分布式交易系统设计和实现

摘 要：本文提出了基于SP/MC的网络模型。描述了一种基于该模型的分布式交易系统的设计和实现。介绍了该系统的总体设计架构和分布式结构，然后描述了系统如何实现各种分布式特性及一些通用服务的实现，如：异构系统接入，负载均衡，延迟重连。最后通过多次实测数据，展现了基于SP/MC网络模型的性能和基于该模型的交易系统性能。

关键词：单生产者-多消费者网络模型；分布式交易系统；网络模型

中图分类号：TP3

随着NFC技术的普及和移动APP的兴起，移动支付即将迎来高速增长期；通过技术改造和系统优化，使得移动支付系统在可靠性，可用性和性能方面都有不同程度的提升，现已具备处理每秒万笔交易的能力。高效的网络通信框架和系统分布式化是解决海量客户请求的两个关键技术。

现有高性能网络通信框架在事件分发和通知的实现主要使用Reactor模式实现[1]，事件分发后对后续数据的处理没提供相应的模型（一般由用户自己实现）。生产者消费者模型是最早用于经济领域的模型，之后被引入计算机领域中用于解决并发和同步问题，如：该模型在多核并行计算中的应用[2，3]，该模型可以作为多核环境下的编程范型[4]。生产消费者模型（P/C）的本质是通过引入缓冲区在一定时间内缓解生产者和消费者之间的速率不匹配问题。在一定前提条件下，通过调整缓冲区大小，生产者和消费者的比率等方式都可提高P/C模型的效率。交易系统的后台业务逻辑复杂，数据处理操作与接收数据请求相比耗费时间更多，符合P/C模型（单生产者多消费者模型，即SP/MC模型）的应用场景以解决系统中临界资源的共享管理。

分布式系统的高可靠，高可用和横向扩展能力是解决大量客户请求的有效手段[5]。分布式系统多实例部署结构，提高了可用性和系统吞吐量。多实例之间互为热备，也加强了系统的可靠性。分布式系统可简单通过系统实例的简单增加即可满足前段请求剧增的需求。因此，交易系统的分布式化是大交易系统改造的趋势。

本文提出了基于SP/MC的网络模型。描述了一种基于该模型的分布式交易系统的设计和实现。介绍了该系统的总体设计架构和分布式结构，然后描述了系统如何实现各种分布式特性及一些通用服务的实现，如：异构系统接入，负载均衡，延迟重连。最后通过多次实测数据，展现了基于SP/MC网络模型的性能和基于该模型的交易系统性能。

1 基于SP/MC的网络模型

生产者和消费者模型（P/C Model）可以适用于多种应用，是一种解决并发问题的经典范型[6-9]。根据P，C数目不同，P/C模型衍生出四种类型：单生产者-单消费者（SP/SC），单生产者-多消费者（SP/MC），多生产者-单消费者（MP/SC），多生产者-多消费者（MP/MC）。

1.1 SP/MC模型

生产者和消费者之间对数据的处理是独立进行，但是其交换数据使用了共享资源，一般使用队列作为缓存，两者对队列的存取是并发进行，因此，需要使用一些同步方式保护共享资源。当队列中数据满的时候，生产者无法再生产，必须等待消费者，消费者取出队列数据时发出事件通知生产者，才可继续生产数据；同理，当队列为空时，消费者必须等待生产者，生产者生产数据并发出事件通知消费者，才可继续处理数据。文献[10]提出了常用P/C模型的描述，如图1所示，P和C之间使用队列（Queue Buffer）实现，共享资源队列使用Monitor方式同步。Monitor除提供了对buffer提供互斥锁序列化读写操作，还提供一种事件通知机制。P写入数据至Buffer前，先判断Buffer是否满，满则等待；如果Buffer不满则添加数据，添加数据后使用semaphore通知C。C从Buffer中读取数据前，先判断Buffer是否为空，空则等待；如果Buffer不空则获取数据，获取数据后通知P。

生产者的能力与消费者的能力比例影响了选择的模型。如果P和C的能力相近时，使用SP/SC比较合适；当生产者能力较强时，使用SP/MC比较合适；当消费者能力较强时，宜选用MP/SC模型；MP/MC是如上三种模型的普适性抽象。通过实验验证了MP/MC模型随着CPU的增加，效率有明显提高。但是，P和C的数目也不是越多越好，P和C数量的增加导致系统资源的开销和系统调度负载的增加，影响系统的整体效率。由于实际系统的业务和环境的差异，M的取值的预先确定是个难题，一般基于经验结合多次实验结果综合考虑后确认[11]。

1.2 基于SP/MC网络模型

交易系统的网络通信子系统可抽象为一个P/C模型。系统外部客户端发起大量并发请求，系统接收请求后，将各种请求交付给不同的请求处理服务程序进行数据接收，数据解析，数据处理等操作，最后将处理结果写入网卡返回给客户端。网络请求处理程序的处理过程可抽象为消费者，系统对网络请求的接收过程即可抽象为生产者。

交易系统的外部客户端数量和并发请求较多，在短时间内可发起大量网络请求。请求的后续处理有许多费时的操作。交易系统的请求的生成能力远大于请求的处理能力，即生产者的生产能力远大于消费者的处理能力，因此，选用SP/MC或MP/MC模型比较合适。

现代操作系统（Linux，Unix，Windows等）提供了非常高性能的Polling机制用于监视网卡的IO请求，如IOCP，EPOLL，KQUEUE等[12]。使用Polling机制很容易同时接收许多网络请求事件。如图2所示，本系统在一个线程里使用EPOLL实现生产者（SP），用于获取用户的请求通知；使用多个线程实现多个消费者（MC），处理后续比较耗时操作，如：数据格式的解析，多次写入和查询数据库操作，递交给其他服务处理并等待返回等。

根据交易系统的实际需求和特性，使用基于SP/MC的网络模型作为核心架构，利用操作系统的EPOLL技术实现生产者，仅需一个生产者即可实现上万并发的请求，减少了操作系统的开销，提高了整体系统的效率。使用多个消费者并行处理耗时的后续数据处理工作，充分利用了CPU的多核心并发技术，提高了硬件资源利用率，减少硬件成本。

2 系统总体设计

在线交易系统的总体层次结构一般由外部接口层，业务逻辑层，数据存储层组成。根据实际业务的特点和行业实践经验，各种系统对每层的功能和内部结构定义都不尽相同。

2.1 总体系统架构

以技术实现角度分类，本系统分为WEB层和APP层，系统的总体结构如图3所示。

外部接口支持HTTP协议和Raw Socket两种接入方式。HTTP协议的接入和Raw Socket的接入分别在Web层和APP层实现。Web层提供两种接入方式：带界面显示的接入和API级别的接入，例如：移动和PC客户端的接入需要显示界面，而外部客户系统的接入主要是使用基于HTTP/HTTPS的API接入。APP层也提供一种基于Raw Socket的接入方式，主要面向可信任的系统。

业务逻辑层和数据存储层在APP层中实现。业务逻辑分为交易相关服务，交易无关服务和通用服务。交易相关服务是本系统的核心服务，为提高可靠性和安全性将其独立实现，包括消费相关，公用缴费相关等交易。交易无关服务主要是为移动和PC客户端服务的功能，如：用户登录管理，用户相关信息查询和推送，系统基本信息维护等。通用服务包括交易系统常用的各种服务：全局唯一序列号生成服务，常用信息查询服务，加密服务，短信通知服务等。

数据存储层以关系数据库为主，实时存储所有交易数据，关系数据库支持DB2和MYSQL数据库，关键数据存储于DB2数据库中。对系统中非长期保存的数据使用Key-Value的形式存储于内存缓存服务中。对变化较少访问量较大的数据使用两级存储，最准确的数据存储于关系数据库中。

2.2 分布式物理结构

本系统是一个基于RPC的分布式集群，详细的系统物理连接结构如图4所示。Web层和APP层都包括了多台物理机，每台物理机上部署了一套系统实例，同时提供服务。Web层与APP层之间使用基于自有协议的跨语言RPC方式通信。Web层与APP层的各个实例之间使用全连接的方式。

Web层的主要功能是界面显示和HTTP协议适配。APP层则实现业务功能和存储。APP层中每一个系统实例对外仅有一个Proxy服务，提供统一的调用接口。根据业务逻辑的特点和共性，提炼了一些逻辑简单的通用服务（序列号生成服务，加密服务，短信服务等），提高了服务的重用性。内部各个服务是独立运行（进程），个别服务的崩溃不会影响其他服务的运行，增强了系统的可用性。各个服务之间使用统一的RPC机制通信，有利于快速增加新服务。

Web层和APP层的分布式集群部署，提高了系统的整体吞吐量和性能。使用分布式部署，各个系统实例之间互为热备，提高了整个系统的可靠性和可用性。关键数据使用唯一的高性能数据库存储，保证了交易系统数据的高一致性。APP层内部通过对服务流程提炼和业务关系抽象，形成了一些通用服务，简化了业务实现流程，减少了新需求开发、测试和上线时间。

3 系统的分布式特点实现

基于SP/MC的网络模型为单个服务的高性能提供了保证。整体系统的可靠性，可用性需求是通过系统的分布式化以满足。交易系统对性能，可靠性，可用性和一致性都具有较高的要求，而分布式系统的结构特点决定了其可较好的满足高可靠性，高可用性和高性能的要求[5]。

3.1 异构系统接入

本系统面向客户群有个人，公司，机构和内部其他系统等。接入的客户端系统运行于多种平台，如Windows，Linux，Android，IOS，Unix等。本系统提供两种通用的接入方式解决异构系统的接入问题。个人和公司的接入主要使用基于HTTP/HTTPS协议接入。机构和内部系统使用自定义的协议――基于通用数据交换的RPC协议接入。个人和公司用户交易量小，安全性验证和权限审核较高。在WEB层使用成熟的异构系统接入标准协议（HTTP/HTTPS协议）提供访问即可满足个人和公司用户的交易要求。个人用户直接使用HTTP/HTTPS协议（浏览器或者客户端）访问系统服务，公司用户使用REST API接口，调用交易系统服务。

在性能和安全性方面，机构和内部系统的接入需求与个人和公司接入不同。前者对性能要求比其他接入方式高，交易系统对机构和内部系统的信任度相对较高，即安全性验证相对较低。机构和内部系统绕过WEB层，直接通过APP层进行接入。APP层实现了跨平台和跨语言的通信协议――基于通用数据交换的RPC协议。本系统开发了C/C++，JAVA，PYTHON，LUA语言的二进制工具库提供给接入机构，既可以保证通信协议的安全性也方便机构的接入。

简要介绍该协议的格式和特点。

（1）协议是基于字符串，所以不用考虑不同平台的字节序问题，同时也有利于调试和问题发现。

（2）协议分为报文头，报文体两部分组成，报文头由固定魔数，版本号和有效内容长度组成。

（3）报文体是基于key-value的多个字段组成，每个字段由名称，类型，字段组成。

（4）协议将数据分为三类，数字，字符串，数组，数组内部可以包含其他任意类型。

该协议和RPC调用机制紧密结合。基于该协议的消息内容可映射为key-value的哈希表结构。RPC在调用前先将所有要素构造为key-value的哈希表，调用结束后，将返回的字节流按照协议映射成为哈希表。支持一门新的语言只需实现协议到哈希表的互相映射即可。这种设计对不同语言的兼容性很友好，实现过程也很简单。

3.2 负载均衡机制及延迟重连

外部客户端对交易系统的访问只有一个入口，但是，后台有多套服务实例为客户端处理交易。在外部入口处，系统配备一台F5硬件负载均衡平衡高负载下每台机器的压力，减少系统宕机的可能。在系统内部，每个服务自己也是负载均衡服务，使用负载均衡的方式与其他服务或者数据库建立多个连接，采用轮询方式均衡负载。

分布式系统的负载均衡策略一般有：轮询机制，随机机制，基于权重的机制。基于权重的机制比其他两种方式考虑因素多，而且实现方式复杂。随机机制平均负载效果没有轮询机制好。特别是在系统较高负载压力下，由于随机性容易导致某些机器长时间负载变大，如果此时一台机器崩溃，其他机器的负载更高，进而引发连锁反应最终系统完全崩溃，停止服务。轮询方式的均衡平均型和实现简单性比其他两种方式优秀，因此，系统内部采用轮询方式实现负载均衡。

分布式交易系统内部服务众多。为减小系统负载和避免不必要的通信浪费，服务之间未采用定时心跳保持连接，而使用TCP长连接保持连接。假设服务A接收请求必须访问服务B才能完成任务。当服务A，B之间连接断开，而服务A接收到新的请求时，服务A会发起定时从重连，一定次数后请求服务失败，并写入错误日志。当服务A没有接收新请求时，服务A不会发起重连机制。通过延迟重连到请求发生时刻，可以避免系统内部过多请求，减少系统资源浪费。

3.3 通用服务

生成全局唯一序列号是交易系统各种业务都需要的功能，甚至所有数据库也都支持生成序列号（Sequence）功能。在分布式系统中，唯一的数据库服务已经是系统瓶颈，无法依赖数据库满足该功能需求。本系统中将该功能抽象独立为服务，其他服务通过统一的RPC接口访问。每个服务将通过序列号标识通过请求发送到序列号服务，序列号通过查找对应的序列号数字加1后保存数据至文件后返回。该序列号生成后一般与时间结合使用，可以方便的保证全局唯一。例如：自动增长序列号取十进制6位掩码，结合全局唯一时间，即可满足每秒一百万笔以内交易量的唯一性需求。通过为不同服务配置不同的编号，将序列号生成规则变为：编号，全局时间和自动增长序列号，序列号生成服务亦可支持分布式部署。

交易系统中常常需要使用参数查询功能，例如：卡号规则，商户信息，银行信息，系统参数等，数据几乎每笔交易都需要查一到多次，但是数据查询虽然频繁，修改间隔较长，一定时间内是只读数据。本系统独立一个服务集中提供参数查询，预先将数据库中所有数据载入内存，查询时使用二分查找法，快速查找。同时，针对数据的可修改性，服务定时从数据库载入所有数据，并使用RCU（Read-copy Update）技术，保证在载入所有数据过程中，不会影响服务向外部提供服务的能力。

本交易系统使用统一的数据交换协议定义了异构系统的接入方式；使用多级负载均衡技术，硬件负载均衡解决对外大量客户端的接入，内部服务之间采用多连接负载平衡方式提高单个服务的吞吐量；延迟重连策略增强了服务的可靠性和可用性；抽象并优化高性能通用服务提高整体系统性能。

4 性能测试分析

本节分别测试了基于SP/MC的网络模型和分布式系统的整体性能。网络模型的性能测试是通过对逻辑简单的单独服务性能而实现，因此也测试了分布式系统中单点瓶颈的极限性能。另一方面，以系统的角度发起常用交易，测试了整个系统的性能以及可扩展线性度。综合两个指标可确定交易系统的性能极限。

交易系统主要数据请求一般来自固定的长连接系统（如，机构和内部系统）。性能测试时，客户端设置为固定数目的长连接，每个客户端连续发起交易请求。性能测试结果统计使用后台缓存日志系统记录交易数据后，再离线统计每秒平均交易量（TPS Transaction Per Second）。这样既避免了多个客户端记录数据时引起的同步困难问题，也保证了计数的准确性。

网络通信框架的性能测试与业务逻辑无关，服务端选用业务逻辑较简单的序列号生成服务。而测试整体系统性能时，客户端发起最常用的交易类型（如：消费交易），后端按照正常业务逻辑处理。测试环境的操作系统为X86-64位SUSE 11，内核为3.0.13，硬件配置为AMD 8-Core，2GHZ处理器，内存16G，硬盘200G，文件系统EXT3。

如图5a所示，测试了客户端增加时对单独服务的TPS的影响。客户端数从1增加到10个时，随着客户端的增加服务的TPS也递增，但是，继续增加客户端，系统性能有增加但是不明显，因此客户端的请求为20已经可以满足单个服务要求。设定客户端为20，测试单个服务消费者数目的变化与服务TPS的关系，如图5b所示，调整服务的消费者数值（M）由1增加到10服务TPS有明显提升，但是，当M大于10后服务TPS不升反降。消费者数值的增加会导致系统对多个消费者线程的调度和同步的性能开销增加，因此，最优消费者数目M应为10。

整体系统性能测试结果中，如图6所示，实线为系统实测的TPS，虚线为理论线性线条，对比可见系统可扩展性比较优秀。三个系统实例时，数据库成为了交易系统的瓶颈，此时数据库服务器的CPU占用率已经达到85%以上，硬盘IO繁忙度为90%以上。

5 结论

本文提出了基于SP/MC的网络模型。描述了一种基于该模型的分布式交易系统的设计和实现。介绍了该系统的总体设计架构和分布式结构，然后描述了系统如何实现各种分布式特性及一些通用服务的实现，如：异构系统接入，负载均衡，延迟重连。通过性能测试，基于SP/MC网络模型和基于该模型开发的分布式交易系统具有优秀的性能。交易系统对关键数据的准确性和一致性要求很高，关键数据的存储必须选用已被业界证明的关系数据库为唯一存储，因此，导致了数据库成为了交易系统的性能瓶颈。如果交易量上升到足够大时，可通过数据库扩容，数据分片，数据库集群等技术提高整体系统性能。

参考文献：

[1]James Coplien，Douglas Schmidt.Pattern languages of program design[M].ACM Press/Addison-Wesley Publishing，1995.

[2]Byrd，et al.Producer-consumer：Communicationin Distributed Shared Memory Multiprocessors[C].Proceedings of the IEEE，1999，Vol 87.Issue 3：456-466.

[3]Liqun Cheng，Carter J.B.，Donglai Dai.An Adaptive Cache Coherence Protocol Optimized for Producer-Consumer Sharing[C].International Conference on High Performance Computer Architecture，2007：328-339.

[4]ArnauPrat-Perez，David Dominguez-Sal，et al.Producer-Consumer： The Programming Model for Future Many-Core Processors[C].International Conference on Architecture of Computing System，2013，Vol 7767：110-121.

[5]Andrew Tanenbaum，Maarten Van Steen.Distributed Systems：Principles and Paradigms （2nd Edition）[M].Prentice Hall，2006，12.

[6]Stefano，et al.Synchronous Producer-consumer Transactions for Real-time Distributed Process Control[C].IEEE International Workshop on Factory Communication Systems，1997：27-36.

[7]Juiz，et al.Improved Performance Model of a Real-time Software Element：The Producer-consumer[C].Second International Workshop on Real-Time Computing Systems and Applications，1995：174-178.

[8]Zhang Y.，Zhang J.，Zhang，D.Implementing and Testing Producer-consumer Problem Using Aspect-oriented Programming[C].Fifth International Conference on Information Assurance and Security，2009，Vol 2：749-752.

[9]Shen C.Discrete-event Simulation on The Internet and The Web[J].Future Generation Computer Systems，2000，VOL.17.Issue2：187-196.

[10]Andrews G.R.，Schneider F.B..Concepts and Notations for Concurrent Programming[J].Computing Surveys.VOL 15.Issue 1.1983：3-43.

[11]Syed NasirMehmood，NazleeniHaron，VaqarAkhtar，YounusJaved.Implementation and Experimentation of Producer-Consumer Synchronization Problem[J].International Journal of Computer Applications，2011，VOL.14.Issue 3：32-37.

[12]W.Richard Stevens，Bill Fenner，Andrew M.Rudoff.Unix Network Programming，Volume 1[M].Addison-Wesley Professional，2003，11.

作者简介：欧鹏（1971-），男，中国银联技术开发中心，高级主管，高工，硕士学位，主要领域：项目管理，质量保证，CMMI，精益6 Sigma，系统架构；庄晓，曾进，王笑，程论，工程师。

作者单位：中国银联股份有限公司技术开发中心，上海 201201