基于中间件的开放式基金登记结算系统

陈松楠

(信阳农林学院 信息工程学院，河南 信阳 464000)

0 引言

现有基金登记结算系统大部分采用C/S的体系结构，如图1所示，这种体系结构虽然能够充分利用两端的软硬资源，但却增加了客户端接入成本，系统对于登记地点、环境多有要求，在异构环境下甚至难以实现客户端与服务器互联互通[1]。现有基于C/S架构的基金登记结算系统也并没有涉及大量实时数据并发访问，数据处理多依靠数据库管理系统自身机制。

图1 客户机/服务器系统架构

在基于三层架构的基金登记结算系统中，IBM公司的消息中间件WebSphere MQ使用最为普遍。消息、队列、队列管理器、通道是构成MQ的几个重要对象，其中，队列管理器是最为重要的一个部件，它管理控制不同的消息队列实现远程通信[2]。队列管理器是为应用程序提供消息服务的机构，网络中每一个队列管理器的名字必须唯一，一个队列管理器可以包含很多不同类别的队列，但是一个队列只能属于一个队列管理器，两个远程队列管理器之间通过代理通道相互传递消息[3]。在消息传递的过程中，作为信息存储的载体，消息队列按照不同的功能分成不同的类别，这和基于高级消息队列协议的消息中间件区别较大[4]。MQ依靠消息头中所含的路由信息来实现数据的正确传送，消息路由信息由目标队列名和队列管理器名组成，整个消息路由过程如图2所示。服务进程C在处理完成一个请求之后，返回一个确认给消息通道，请求进程将已经处理的消息从队列中删除，服务进程通过get方法从队列中不断地获取未处理的消息。

图2 消息在WebSphere MQ中的路由过程

1 基于交易内容的消息路由方法

新模式下基金登记结算系统改变了现有两层实现的体系结构，采用C/S/S的三层体系结构[5],如图3所示。应用程序之间高效透明的数据传送由消息中间件负责，实时交易业务的完整性由交易中间件保证。在三层或多层体系结构中最重要的部件就是中间件。中间件可以看做一个独立的应用软件，它封装了底层硬件的实现逻辑，具有强大的通信能力和良好的扩展性，同时为上层软件提供接口，使程序开发者可以专注于业务逻辑的实现而不必在底层实现上浪费时间，数据高效透明传送以及交易完整性保障这两大功能也可以封装在一个应用实现。

图3 基于中间件的三层体系结构

1.1 高级消息队列协议通信实现过程

高级消息队列协议基本域模型通信原理[6]可以用图4来描述，从图中可以看到交换器和消息队列构成了Broker的基本单元，其被定义为虚拟主机(Virtual Host)。一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host。客户端程序想要和Broker沟通就必须建立起与Broker的连接，这种连接是与虚拟主机相关联的，其本质是客户端程序到Broker的TCP连接。可以在一个连接上并行多个通道，每一个通道执行与Broker的通信[7]，如果在大量数据请求的情况下，暂且不考虑TCP连接是否浪费，单论操作系统也无法承受每秒建立如此多的TCP连接。高级消息队列协议规定只有通过通道应用程序才能执行相关命令，因此仅仅建立了客户端到Broker的连接后，客户端还是不能发送消息的，还需要为每一个连接建立起通道，之后才能调用命令。

图4 高级消息队列协议模型层通信实现过程

在会话层，为上层所需要交互的每个命令分配一个唯一标识符，以便在传输过程中可以对命令做校验和重传。命令发送端也需将每个发送出去的命令记录到重发缓冲区，以期得到接收方的回馈，保证这个命令被接收方明确地接收或是已被执行。对于超时没有收到反馈的命令，发送方再次重传。如果接收方已明确地回馈信息想要告知命令发送方，但这条信息在中途丢失或是其他原因发送方没有收到，那么发送方不断重传会对接收方产生影响，为了降低这种影响，命令接收方可以设置一个过滤器，来拦截那些已接收过的命令。

1.2 基于交易内容的消息路由方法

一个虚拟主机中会存在多个消息队列，交换器要做到将消息准确发送到相应的消息队列中。消息队列的创建是由客户端程序控制的，在创建消息队列后需要确定它来接收并保存哪个交换器路由而来的结果，绑定就是用来关联交换器与消息队列的域模型。在与多个消息队列关联后，交换器中就会存在一个路由表，这个表中存储着每个消息队列所需要消息的限制条件。在每次收到客户端请求消息后交换器就会检查它接收到的每个消息的消息头和消息体信息，来决定将此消息路由到哪一个队列中去。

消息中间件域模型核心服务根据用户程序中定义的交换器类型为消息提供不同的路由机制，当投资者发起基金申购、赎回交易业务时，在应用程序中标记此类请求消息消息头的RoutingKey值为Buy，定义交换器类型为Direct，如图5所示。在某一时刻生产者进程发出的消息被传送到交换器，交换器首先检查消息头的RoutingKey属性，并在路由表中查找匹配，路由表中记录了用于绑定交换器和队列的BindKey的值，在此要特别注意的是，交换器可以和某一消息队列有多个绑定值，也就是说消息路由关键字的消息可以传送到一个消息队列之中，通过精确匹配消息的路由关键字，将消息路由到零个或者多个队列中，客户端程序在每一个队列端又定义了一个或多个相对应的消费者，这样就把生产者和对应的消费者联系了起来。根据Direct类型交换器进行进程通信时的路由规则，可以构建经典的点对点队列消息传输模型[8]。从图5可以看出，当某个客户端消息到达交换器X时，此消息的RoutingKey为Buy，将消息发往消息队列Q1。

图5 交换器为Direct属性下基金申购数据路由规则

每日基金清算过程中，要处理大量的当日账户数据和交易数据，清算任务虽然没有实时性的要求，但是却涉及大量表处理操作，清算过程中的每一步又可以分成许多子处理步骤。可以设定交换器为topic即主题类型，根据清算工作的复杂程度来分发相应的处理程序。其本质上就是利用模式匹配来实现消息和相关处理队列的绑定过程。

这种消息路由器机制可以被用来支持经典的发布/订阅消息传输模型，使用消息路由关键字中定义的主题名字空间作为消息寻址模式，将消息传递给那些部分或者全部匹配主题模式的消费者[9]。此种模式下绑定关键字由零个或多个标记构成，每一个标记之间用“.”字符分隔，绑定关键字必须用这种形式明确说明，并支持通配符“*”匹配一个词组，“#”匹配零个或多个词组。如图6所示，首先在客户端程序定义交换器为主题式类型，图例中定义了“#.Acct.*.*”、“*.Acct.#”和“*.Acct.*”三个绑定关键字,它们分别对应了消息队列Q1、Q2和Q3，当带有路由关键字“CPrep.Acct.Clear”的消息，也就是账户清算处理前的请求传送到主题式交换器时，查找路由表后与“*.Acct.#”、“*.Acct.*”匹配，但不与“#.Acct.*.*”匹配，因此消息传送到Q2和Q3队列。

图6 基金清算过程中基于主题的消息路由规则

每日日终，当日清算工作处理完成之后，基金登记结算系统会向电商系统发送投资者的收益数据，在应用程序设计定义交换器类型为fanout即广播类型。它实现了这样的消息路由机制:不论消息路由关键字RoutingKey值是什么，这条消息都会被路由到所有与该交换器绑定的消息队列中，如图7所示。广播式交换器类型的工作方式如下：不使用任何参数将消息队列与交换器绑定在一起，也就是说在客户端程序中不用设置任何BindKey的值，当发布者(在此种模式下直接式交换器类型描述中的producer变成了publisher，已经隐含了两种交换器类型的区别)向交换器发送一条消息，此消息将被无条件地传递到所有和这个交换器绑定的消息队列中。在图7中，从客户端进程P发送到交换器X的所有消息，将被送到所有和交换器绑定的Queue上，消息队列Q1、Q2和Q3都能收到P发送的消息，也即是投资者都能查看到相应的基金收益数据。

图7 交换器在广播属性下的基金收益数据路由规则

2 实验结果与性能分析

电商系统实时将投资者的开户、申购、赎回等请求数据传送到基金登记结算系统，系统对数据处理后，实时给出应答消息。本节对系统在LoadRunner压力测试工具[10]下模拟开户、申购、赎回，分析基于中间件的开放式基金登记结算系统在一定数量的并发请求过程中，消息中间件和交易中间件CPU的使用率以及系统处理每个事物的平均响应时间。

基金开户性能测试的过程中，平均事务响应时间如图8所示。在平均每秒开户185笔时，消息中间件和交易中间件的CPU使用率在1%～8%之间，内存使用率在2%～7%之间。

图8 在60个投资者并发开户情况下平均事务响应时间

基金申购性能测试的过程中，平均事务响应时间如图9所示。在已有680万账户存量，平均每秒申购交易267笔情况下，消息中间件和交易中间件的CPU使用率在1%～8%之间，它们的内存使用率在2%～7%之间。

图9 在60个投资者并发申购情况下平均事务响应时间

基金赎回性能测试的过程中，平均事务响应时间如图10所示。平均每秒发起307笔赎回交易，系统消息中间件和交易中间件的CPU使用率在1%～8%之间，内存使用率也在1%～8%之间。

图10 在60个投资者并发赎回情况下平均事务响应时间

3 结论

本文介绍了面向登记结算系统的消息路由方法的实现过程。首先，分析了现有基金登记结算系统中间件的三层体系结构，并对基于此体系结构实现的基金登记结算系统的应用层次进行了介绍。其次，分析了高级消息队列协议应用通信实现过程，并在此基础上提出了基于基金交易内容的三种消息路由方法。最后，对基金登记结算系统进行性能测试，通过LoadRunner模拟在大量并发数据下系统对实时交易申请数据的响应，并对每日日终完成清算流程各步骤所需要时间进行测试。实验结果表明该系统基本能满足基金结算的需求。

[1] BERTOCCO M, FERRARIS F, OFFELLI C, et al. A client-ser ver architecture for distributed measurement system[J]. IEEE Transactions on Instrumentation and Measurement Technology,1998,47(5): 1143-1148.

[2] SANCHER T. IBM MQ series and WebSphere MQ interview questions[M]. New York： Equity Press,2007.

[3] DAVIES S, COWEN L, PARKER H. WebSphere message broker basics[M]. New York: International Business Machines Corporation, 2005.

[4] VINOSKI S. Advanced message queuing protocol[J].IEEE Internet Computing, 2006,10(6): 87-89.

[5] MAHMOUD Q. Middleware for communications[M].Chichester: John Wiley & Sons Ltd, 2004.

[6] HINTJENS P. ZeroMQ: messaging for many applications[J]. O’Reilly Media, 2013, 23(1): 646-652.

[7] LUI M, GRAY M, CHAN A, et al. Enterprise messaging with JMS and AMQP[M]. Pro Spring Integration, 2011.

[8] 李知杰. 基于AMQP的异步通信实现及其在OpenStack项目中的应用[J].软件导刊，2013, 12(7)：35-37.

[9] 杨萍，李杰. 利用LoadRunner实现Web负载测试的自动化[J].计算机技术与发展，2007, 17(1): 242-244.

[10] 余益民. 统一全国证劵登记结算系统的探讨[J].中国金融，2010(3): 30-33.