基于消息队列的前置系统数据库同步转异步方案设计

付霞

(上海杉达学院，信息学院， 上海 201209)

目前我国的金融系统领域电子化趋势领跑全球，支付电子化已深入到我们老百姓日常生活的方方面面，可以说，我们的日常生活已经离不开电子化的支付方式了，因此支付领域的安全与高可用已经上升到国家安全层面了，每个金融机构在监管的要求下，都在不遗余力的提升自己系统的安全性与稳定性[1]，确保系统的高可用。同时，面对日趋激烈的市场竞争环境，各金融机构还需要确保自己系统的客户体验要好，以免造成客户的流失。因此，各机构电子银行渠道针对客户开放的渠道也是越来越多，就拿普通的城商行来说，目前至少存在以下渠道[2]：微信、支付宝、银联、客服、电话银行、手机银行、网上银行、柜面、ATM、短信。同时，金融机构内部还存在类似核心系统、客户管理系统、审批系统、授信系统、差错调账系统等等各类功能性系统，这些系统往往都是独立的子系统，各系统需要与前端渠道进行交互，同时各系统之间又存在互相调用的情况。而为了保证各系统核心部分功能的独立性，往往都会建设一套独立的前置系统(FES)，该系统主要负责报文的路由控制、通讯协议转换、报文格式转换、事务一致性控制、分对总接入、密钥等安全管理等[3-4]。该系统作为各系统的入口，控制着各系统的流量，因此该系统的健壮性及高可用对于金融机构的业务开展至关重要。

1.1 FES常见架构说明

如图1所示，渠道端对接客户或内部工作人员，将不同的业务转成不同的联机交易发送至FES的不同通信模块，通常FES支持的通信方式有TCP长连接(单双工)、TCP短连接、HTTP(S)、MQ等[4]，通信模块将接收到的完整报文发送至路由模块的消息队列[5-6]；
路由模块根据不同的业务类型将报文转发至不同的业务处理模块所对应的消息队列中；
各业务模块完成相应的业务逻辑处理后，将报文发送至对应核心系统的通信模块的消息队列中，通信模块负责将报文送至对应的核心业务系统，完成请求报文的整个链路。核心业务系统处理完请求报文后，通常会有响应报文返回，而且响应报文一般需要按照原路进行返回如图2所示。

图1 FCS常见架构

其中FES各进程之间通过消息队列进行信息交互，业务处理模块需要跟数据库进行交互。

1.2 FES的数据库交互操作说明

FES的功能主要是路由控制、通信协议转换、报文格式转换、事务一致性控制、分对总接入、密钥管理。因为基本没有业务数据需要保存，那么FES使用数据库的主要目的是为了满足其中的路由控制和事务一致性控制功能需要。

以其中的路由控制为例，因为要确保交易的原路返回，所以在接收到请求报文时需要将请求的信息先记录到数据库中(需要进行insert和update操作)，响应报文回来时，需要通过查询数据库来匹配到原请求报文(需要select操作)，进而找到响应报文的返回路由信息进行原路返回，如图2所示。

图2 交易链路及数据库交互

1.3 FES的雪崩效应产生原因分析

雪崩效应[7]通常指的是：起初只是一个小小的扰动，但是事态发展越来越严重，往往成几何级数增长。而对于一个IT系统来说，当一笔业务所经过的链路中出现A资源等待时，会造成该笔业务耗时过长，同时后续业务因此出现排队等待现象，因后续业务也需要占用其他的系统资源如B、C等，进而造成B、C资源的不足，最终导致整个系统各模块均不可用，这就是IT系统的雪崩效应。

而FES的运行需要依赖硬件、操作系统平台及数据库，一般来说，因为硬件可以根据需要进行升级，操作系统一般不会是IT系统的瓶颈，所以对于FES来说，数据库往往是瓶颈所在，也是雪崩效应产生的根源(对于某些业务，可能会使用到加密机，加密机往往也是瓶颈所在，本文不讨论对于加密机访问瓶颈的优化)。

如图3所示，当数据库响应慢的时候，路由模块还会持续不断往消息队列B发送报文，如果消息队列B被堵满的话，路由模块则无法继续工作；
进而导致消息队列A的报文无法处理，这又会导致消息队列A被堵满；
进而导致通信模块无法继续工作，通信模块如果是短连接的话，因为报文没能及时返回，进而导致连接池资源很快被占满，这个时候整个FES将无法对外提供服务，产生雪崩效应。

图3 FES雪崩效应图

2.1 同步与异步机制

通过上面的说明可以看出，FES系统之所以会产生瓶颈及雪崩效应，主要在于链路上存在资源依赖，尤其是数据库资源,而一旦数据库资源得不到满足，整个链路都被迫处于等待。这时我们把数据库与应用之间的交互机制称为同步机制。

同步就相当于是当客户端发送请求给服务端，在等待服务端响应的请求时，客户端不做其他的事情。异步就是当客户端发送给服务端请求时，在等待服务端响应的时候，客户端可以做其他的事情。

如果FES的数据库访问能够将同步机制转换为异步机制[8]，那么就可以解决FES目前碰到的问题了。

2.2 同步转异步的2个问题

要解决FES的同步转异步的问题，需要解决以下2个问题。

(1) 业务数据的低敏

同步转异步以后，那么也就意味着原业务在数据库操作可能失败的情况下会继续进行，也就是要保证这些业务数据丢失也不会对业务造成账务上的影响。而FES系统因为是转接系统，不直接保留业务数据，所以，即使是insert或commit失败，也仅仅是应答报文回来后，select不到原交易而无法正常返回，丢失一笔交易。而金融IT系统对此类异常情况都会有对账与调账机制相配套，因此FES对于业务数据来说是属于低敏的。

(2) 缓存机制

同步要转异步，那么必须要有缓存机制，在数据库响应慢时将所有的数据库操作先缓存起来。比较简单轻量化的缓存机制可以采用Linux操作系统提供的消息队列。

2.3 大型数据库与内存数据库的双数据库设计

虽然通过缓存机制解决了偶尔数据库响应慢的情况，但是还存在更极端的情况如数据库长时间响应慢或者不可用的话，这时也会导致应用与数据库之间设立的缓存空间被占满，进而导致系统完全不可用状态，所以，如果能够使用双数据库来进行热备的话，则可进一步提高系统的健壮性和高可用性。

3.1 数据库同步转异步架构说明

原FES业务处理模块与数据库之间交互是通过数据库本身提供的API进行交互。新的架构里面，FES业务处理模块将根据新增的数据库管理模块设计提供的API进行报文组装，并且将组装好的报文发送到消息队列，不直接与数据库管理模块进行通信。数据库管理模块通过从消息队列获取需要处理的报文，并优先将数据库请求发往主数据库进行处理。如果数据库管理模块判断当前主数据库状态异常，则后续将数据库请求发往备数据库。数据库管理模块根据设定的时间对状态异常的主数据库再次进行判定。其中主数据库一般使用比较大型的商用数据库软件，如Oracle、DB2、Informix等。备数据库一般采用开源免费的内存数据库，如SQLite[9]等。备数据库一般是在主数据库状态异常时才会暂时接管数据库请求。对于响应报文回来的select操作，一般也是优先到主数据库中进行查询，如果搜索不到则到备数据库中再次进行查询。

3.2 双数据库下的数据库连接池说明

为了提高业务处理能力，数据库管理模块会根据业务量动态地对直接与数据库进行交互的进程DBAP的数量进行管理(见图4)，每个DBAP都会采用竞争模式从同一个消息队列里面获取报文并与数据库进行交互后，将获得的数据库返回信息按照约定的API进行报文组装，并发送到指定的消息队列中。每个DBAP都具有与双数据库进行通信的能力，所以将这些DBAP的组合称为双数据库下的数据库连接池。

图4 数据库同步转异步的设计架构图

本文主要介绍了金融系统中非常常见的一种IT系统前置系统的常见架构模式，基于该架构模式下，又说明了数据库访问性能瓶颈会导致的整个系统的雪崩效应是如何产生的，为了解决这种性能瓶颈与雪崩效应现象，分析了原因并指出通过将数据库的访问模式从同步转成异步即可，而为了对数据库进行同步转异步，又说明了必须具备的前提条件，最后，提出了解决方案并对解决方案进行了详细阐述。同时，本解决方案所提出的问题解决思路在前置类系统中很多需要调用外部资源的场景下都有较好的通用性，如加密机资源瓶颈等。