第 1 章 绪 论
1.1 课题背景及研究的目的和意义
随着互联网的飞速发展，人们对其的要求也越来越高，在日常生活中参与的互联网活动也越来越频繁，这直接导致大中型银行的核心系统[1]在面对高并发实时交易[2]的压力越来越大，同时核心系统峰值查询能力的压力也在不断地上升，用户行为[3]和用户规模的不可预测性预示着，采用传统的数据库已经不能满足系统高效性的需求，核心系统非常有必要的增加其数据库的线性扩展能力[4]。目前，很多银行的核心系统数据库都是采用集中式的方法，而随着互联网和人们需求的飞速发展，其处理能力的峰值逐渐面临着挑战和考验。例如在发布时，集中式数据库不能很好地满足业务需求，如果将大部分必要的需求集中在同一时间发布，例如系统某个版本的上线、升级与变更等，都需要很高的时间成本，势必会对其市场反馈速度造成一定的影响。数据库转型路径决定了未来银行业务模式[5]的走向。为适应市场发展需求，完成公司新一代交易平台的搭建，进一步完善基础架构，组建稳定可靠的新一代交易数据处理框架非常有必要。交易数据处理框架是新一代交易系统的核心组成部分, 它通过一部分外围业务，尝试建立内存数据库[6]，并利用发布订阅模式（Pub/Sub）[7]来进行系统的交互，以提高系统的运行效率和服务器的性能。它接收来自撮合服务推送的交易元数据，通过行情计算组件计算市场行情、可成交行情数据并推送给下游订阅客户端或系统，是一个实时数据处理，发布订阅服务开发框架。我们论文的课题就是在这样的背景下产生的。
1.2 与本课题有关的国内外研究状况
本课题涉及到数据库转型和发布订阅模式的内容。现在大多数银行的核心系统是“瘦核心”[8]，只做交易，而核心交易和总账是松耦合的，真正的核心交易量并没有大到要改变框架的程度，反而是随着交易复杂度、业务量的激增，更多的交易压力转向外围的总账处理，如果从广义上把总账和主要外围应用都纳入核心系统考量，确实需要考虑用分布式数据[9]库替代，以应对互联网时代海量数据实时/准实时处理[ 10]、反欺诈查询[11]的压力。在这样的情况下，核心系数据库的转型之路，层次较为清晰。在账务交易类部分，如果核心核心业务模式出现更小、更为简化的颗粒度变化，向原子化方向发展，分布式数据库应用是有可能的。目前来看，基础存贷汇交易具备了原子化的条件，但对公交易、客户理财反而是走向复杂化趋势，客户需要复杂的逻辑评比以解决诉求，类似交易就不适用于做分布式数据拆分。随着银行业务和系统的不断扩展，系统账户数量与交易类型数量也在不断上升，交易场景的灵活性也在不断增强，银行面对着前所未有的挑战，在这样的形势下，采用分布式数据库，看似可以增加系统的抗压能力，但从当前技术发展，银行内控，监管要求来看，将核心系统引用全部采用分布式数据库，还需要很多条件，挑战极大。最近一些国内厂商和互联网公司推出了支持强一致性的分布式数据库产品，但据了解，只支持单节点事物，不支持跨结点事物[12 ]。国外的数据库产品，虽然通过分布式框架基本满足了高扩展性的要求，并且具有全局事务管理功能，但其事物管理中的隔离级别是否满足银行核心业务系统的要求，还存有疑问。总体看，用分布式数据库做核心系统的技术条件尚不完备，目前还找不到完善的分布式数据库实施方案。移植方案对核心系统业务逻辑影响较小，可避免重新开发和修改应用。国内有关厂商做了相关测试后得出结论是：如果用“小型机+集中式数据库”的方案替代主机，迁移工作量较小，目前系统性能可以满足业务要求。但是数据库存在逻辑故障，风险较大，必须对集中式数据做加固，显然不能达到银行核心交易系统高安全性，高可靠性的要求。
..........
第 2 章 实时发布订阅系统需求分析
2.1 业务需求
本实时发布订阅系统是为公司新一代交易平台服务，利用部分外围业务，对现有系统的一种改造。目前具有的业务如下：（1）接收前置服务发送的交易、订单、成交、授信额度、行情等消息，存入接收队列中，并要保证数据的连续性、一致性。（2）存储交易、订单、成交、授信额度、行情等数据到新研发的内存数据库中。（3）将接收队列中的数据，分别进行数据计算、存取，发布等业务处理。（4）用户可以订阅相关主题的行情、报价信息等信息，系统可以实时准确地将用户所需要的信息先进行过滤，再推送给相应用户，也可以推送其他系统、客户端。（5）需要维护各个业务组件的链路关系，保证系统的松散耦合性。
.........
2.2 功能需求
根据业务需求可知，系统应该具有如下的功能：数据接收功能：接收前置服务发送的交易、成交等数据，存入接收队列，支持断点续传等补漏机制，确保数据的连续性，即数据的接收和补漏。存取功能：负责存、取数据，如交易、订单、成交、授信额度、行情等消息，是基于 MDB 的数据存储，并支持索引查找。数据处理功能：根据业务的类型，将组件分类，每次调用特定的组件进行相关业务处理，实现解耦。组件之间可以通过 MDB 进行数据共享。消息推送功能：（1）发布主题管理。该模块需要提供创建、销毁等必要的接口，并通过相关配置文件来加载一系列参数信息。（2）消息发布。将消息存入对应的主题的过程。（3）消息推送。将经过特定组件处理过的内存数据库中的消息推送给订阅的用户。（4）推送数据过滤。推送过滤模块与相关主题绑定，模块需要根据主题中消息内容与订阅者订阅内容进行过滤，将准确的信息推送给最终用户。（5）订阅管理。主要负责维护参与订阅双方的关系。链路管理功能：负责服务启动与停止、用户登陆与服务登陆、用户注销和服务注销、链路断开和心跳处理。
.........
第 3 章 实时发布订阅系统设计 .............. 12
3.1 实时发布订阅系统总体架构.......... 12
3.2 实时发布订阅系统详细设计.......... 13
3.2.1 数据接收模块设计........ 14
3.2.2 MDB 操作模块的设计 ............. 15
3.2.3 数据处理模块的设计 .............. 19
3.2.4 消息推送模块的设计 .............. 25
3.2.5 外部接口设计..... 28
3.2.6 系统运行设计..... 30
3.3 本章小结.......... 37
第 4 章 实时发布订阅系统的实现.......... 38
4.1 实时发布订阅系统实现 ....... 38
4.2 本章小结.......... 61
第 5 章 系统测试............... 62
5.1 测试环境.......... 62
5.2 数据接收模块测试 ............... 62
5.3 MDB 操作模块测试.............. 63
5.4 数据处理模块测试 ............... 73
5.5 数据推送模块测试..... 76
5.6 本章小结.......... 77
第 5 章 系统测试
5.1 测试环境
测试项目：当在多线程工作环境下，CRUD 操作能否正确执行。测试目的：异常测试。预置条件：数据库打开成功。测试数据与步骤：（1）创建一个数据库，最大记录数设置为 100000 条；（2）创建多个不加锁的插入、删除、更新、查询线程、同时对数据库进行操作，同时验证上述操作的完成正确性。该操作进行 3 小时以上；（3）停止上述操作，对数据库的空余空间进行记录插入，填充到数据库的最大记录数；（4）校验整个数据库所有记录的数据正确性；（5）删除数据库中的所有记录；（6）通过数据库总记录数是否为 0 来判断数据库中的记录是否已经被删除。
...........
结 论
在撰写论文期间，作者研究了近年来国内外的文献资料，对目前国内外银行核心系统数据库技术和 Pub/Sub 技术以及相关研究现状，进行了分析和研究，重点在于数据库转型技术。论文的主要工作如下：
（1）通过公司部分外围业务，研究数据库转型技术，基于当前版本工作数据和业务数据都暂存在内存中，即处理的业务每时每刻都是在与实时内存数据库的数据如业务、版本等数据打交道，使得客户端通过直接访问内存数据库，避免直接访问物理数据库，来提高前台查询速度，并通过测试以试验和检测银行交易系统数据库转型方案的可行性和可靠性。
（2）研究了目前 Pub/Sub 的通信模式的不同分类和不同特点，根据现有的技术和公司的实际情况，选择合适的通信模式，利用公司部分外围业务实现其发布订阅功能。
通过研究可以得出以下结论：
（1）通过内存数据库的性能测试和压力测试，我们可以看出，以银行部分外围业务为基础实现的数据库转型技术是成功的，它使得系统效率得到了明显地提升，并且提高了物理数据库的安全性，具有一定的可行性和可靠性。
（2）已经运用 Pub/Sub 模式成功地实现了系统的发布订阅功能，应用这种通信模式不仅了解决发布者和订阅者直接代码级别耦合也解决了两者在物理部署上的耦合，从而提升了系统的整体效率，并且这种通信模式可以扩展到公司后期更多的移植业务上来，起到一个不可或缺的关键中间件的作用。由于目前，我们只是利用部分外围业务就行的数据库转型实验，还没有实现核心系统的全部迁移，很多情况考虑还不全面，这必将会遇到新的困难和挑战，而且目前对银行核心系统数据库的分布式方案还不够成熟，所有还有很多极具挑战性的工作需要完成。
..........
参考文献（略）