基于交易报文的数据实时同步方法研究

尚 海 鹰

(上海久誉软件系统有限公司 上海 200233)

基于交易报文的数据实时同步方法研究

尚 海 鹰

(上海久誉软件系统有限公司 上海 200233)

概括并分析了计算机信息系统中常见的异地数据同步方法。针对事务处理系统的大业务量场景，纯系统级的数据实时同步方法受限于线路带宽的制约。提出的基于交易报文的数据实时同步方法，将事务处理系统的交易报文归纳为应用级的报文重做日志，采用报文分解与封装、报文同步与缓冲池管理等方法与策略，以很低的线路带宽实现业务数据的实时同步目标。通过真实业务数据系统性的实验与分析，验证了方法的可行性与有效性。基于提出的方法，大业务量下应用级容灾备份的实现成本可显著降低。

事务处理系统 容灾备份 重做日志 数据复制 数据恢复目标

0 引 言

随着计算机信息系统在互联网时代的业务模式不断创新，人们对网络应用的依赖愈益紧密。各类金融信息、隐私信息散布在网络化的信息系统中，这些数据关系着广大用户及企业的切身利益。近几年来，黑客入侵、业务数据窃密、数据篡改伪造、蠕虫与勒索病毒等非法行为在网络上的施虐已引起社会各界的高度警觉[1]，信息安全形势日趋严峻，信息系统的业务持续性及业务数据保护丝毫不可懈怠。

依照国家有关计算机信息系统安全保护等级划分准则，关键业务信息系统拟在异地建立一个应用级的灾难备份中心，通过数据同步技术，保持两地业务数据的一致性与完整性。

数据同步作为异地灾难备份的核心任务，需要部署相应的设备设施及租用广域网线路。企业在这类信息安全措施上的投入是没有直接回报的，年复一年的运行费用，对企业是个负担。

对于大业务量的事务处理系统，为避免业务数据的丢失，异地数据实时同步需要占用很高的线路带宽，甚至依赖于裸光纤上的波分复用技术，这样的成本对于效益一般的企业或者非营利性的公用事业单位均难以承受。

本文提出基于交易报文的数据实时同步方法，其目的就是化解大业务量事务处理系统中数据实时同步与实现成本之间的矛盾，以低带宽的线路条件实现业务数据零丢失的备份与恢复目标。

1 事务处理系统的数据复制技术

事务处理系统的业务数据一般由关系型数据库系统管理，主备数据库之间需要维持数据同步。数据同步技术的目的就是维持主备数据库业务数据的一致性。

数据库系统管理着各类数据表，其存储空间依照逻辑关系大致映照为数据库表空间及相关的数据文件、文件系统及相关的逻辑卷或裸设备、磁盘阵列逻辑分配单元LUN及相对应的磁盘卷组(RAID组)。各层面供应商在数据复制这个细分领域各显神通，维持数据一致性的技术与开销也十分复杂，其典型的技术方案，如表1所示。

表1 数据复制技术的分类

磁盘阵列层面的数据复制技术对于上层的操作系统及数据库基本透明，具体的数据复制策略一般可由系统管理员配置与实施。数据复制可以采用异步方式或实时同步方式。该方法采用的技术与存储设备有关，需要存储设备厂商专门软件授权，费用高、灵活性差。鉴于其块结构存储的特点，复制数据的冗余率高[2]，复制流量大，其实时同步方式通常对线路带宽的要求很高。另外，该层面缺乏与数据库事务保护机制的沟通，异步复制方式恢复时容易导致业务数据的丢失，严重时可导致数据库的恢复失败。

文件系统或逻辑卷的数据复制技术与磁盘阵列的数据复制技术相似，但无需依赖特定的存储设备，软件授权成本低。该技术增加了宿主服务器的处理器资源负担，在复杂的计算环境下数据复制的稳定性较差，容易造成备份端系统的数据不一致而导致恢复失败。

面向数据库系统的复制技术通过在线日志或归档日志同步数据，具有显著的稳定性与可恢复性，数据传输的冗余度较低，异步日志传递对线路带宽没有特别要求，一般关系型数据库的内核均支持该方式的数据同步。大交易量的数据库系统若采用实时同步方式传递在线日志记录，则对线路的带宽及稳定性亦有较高的要求。其同步机制相当于跨数据库的二阶段事务提交，异地数据库未成功接收到在线交易日志或未能返回成功的事务重做信息，则本地数据库系统相关事务便会挂起，进而引起业务系统停顿。

数据表的复制一般用于两个独立活动的数据库系统，以维持某类业务数据的一致性。复制哪些表或表中的哪些数据行，与应用系统的设计密切相关[3]，故数据表的复制由应用程序开发者或业务系统维护人员来配置与管理。鉴于数据表管理的复杂性，大型事务处理系统很少采用表级复制技术来实现系统级的异地容灾备份。

本文基于对事务处理系统及其业务流程的深入理解，以应用软件开发及数据库管理的双视角，提出一种融入到应用程序框架的业务数据实时同步方法，意在克服纯系统级数据同步技术的局限性，化解数据同步技术在完整性、实时性与实现成本之间的矛盾，体验异地容灾备份的最佳实践。

2 事务处理系统中的数据流分析

一个规模化的事务处理系统由若干层次构成，如前置通信层或者业务界面层、事务逻辑处理层、业务数据管理层等。业务界面层的服务程序部署在后台的一般为B/S架构，部署在客户端的一般为C/S架构。C/S架构需要在平台测部署前置通信程序，以接收客户端提交的事务交易报文。无论何种架构，前端系统通常将事务封装成约定的交易报文格式交付给后端系统进一步处理。

B/S架构的系统由于界面呈现的元素，如页面、表单、图片等需从后台系统实时获取，互联网业务门户一般部署较高的带宽，但业务界面上的浏览与操作并不会持续产生事务的提交，B/S架构实际事务的提交流量与C/S架构下事务的提交流量相仿。

本文在后续章节中将各类架构的交易报文形成端，统称为交易报文层。

事务处理系统每个层面的数据流量呈金字塔形态，从前端交易报文的形成至后台业务数据的落地，数据流量以量级递增。如表2所示。百字节的单笔业务交易有可能牵动百K字节存储块的变更。

表2 业务数据的层次与流量

各事务处理系统之间通常租用点到点专线进行业务数据交换。三大通信运营商以2 M带宽的DDN、SDH、MSTP等各类型线路为租赁及计费单元，符合实际应用中的业务数据流量需求[4]。单个业务网点通常采用更低的9600 bps～64 Kbps带宽线路或采用逐渐流行的GPRS无线APN方式接入，事务处理后台系统以E1线路或运营商无线APN专网线路等实现广域网链路汇聚，汇聚线路总带宽一般在2 Mbps至30 Mbps之间。

显然，事务处理系统在交易报文的收发端其数据流量甚少，数据冗余度极低，交易报文以精简的格式包罗了事务处理系统的业务变更信息。通常单个交易报文从几十字节到几百字节不等，100万笔的业务量才产生几十兆至几百兆的总数据流量。若将主生产系统收到的交易报文实时复制到异地备份系统，理论上以最小的代价实现了业务数据的同步。

3 交易报文的同步方法实现

3.1 融合同步的策略

交易报文必须经过业务逻辑层的处理才能落地为持久态的业务数据。单纯采用交易报文的同步方式，需要在异地开启活动的应用系统及相应的数据库。这种双活的应用模式实际运用十分复杂。建立在实际业务环境中的数据库管理系统还承担着日常业务管理的访问需求。这些后台管理业务，通过不同的程序对接数据库系统，如此，本地数据库与异地数据库随着活动时间的积累将存在很大的差异性。采用存储系统层面双向数据实时同步的机制，虽可以消除差异，但结构复杂且成本巨大[5]。实际上异地双活应用系统也非必要的业务需求。

为避免两地数据库的差异性，本文提出的交易报文同步方法并非孤立地应用在实际系统中。该方法的核心思想是在数据流量大的底层(如数据库层)采用数据异步复制技术，在数据流量小的上层(交易报文层)采用数据实时同步复制技术，从而弥补系统层数据异步复制造成的近期交易数据的缺失，使数据同步完整性、实时性与技术成本之间的矛盾得以化解。

3.2 交易报文同步方法的构成

本文提出的交易报文实时同步方法建立在事务处理系统应用软件及数据库管理系统的环境下[6]。

生产数据库系统将归档日志传递到异地数据库系统，异地数据库系统将接收到的归档日志重做回备份数据库，这是一个稳定的、成本低廉的备份数据库同步与恢复机制，但备份数据库与生产数据库始终存在着差异(在线日志或未归档日志中的事务数据)。

交易报文的同步方法旨在两地事务处理系统中部署一对交易报文的同步管理程序与交易同步报文缓冲池，简称交易报文同步系统。主系统同步程序将待处理的交易报文分解、验证与再封装，封装后的交易同步报文增加了交易识别号、时间戳、会话标识号等必要的信息[7]，可理解为应用级的交易重做日志，并按设定的工作模式持续地将应用级的交易同步报文传递到异地系统。本地应用系统在处理交易报文的后续流程中将交易识别号等相关信息随数据库事务的提交同步记录到交易状态表。

在灾难恢复过程中，异地备份数据库通过归档日志恢复后，通常处于不完全恢复状态，此时异地应用系统比较交易状态表与交易同步报文缓冲池的相关信息，将差额交易数据提取并重新交付后续应用程序处理，这可理解为适时恢复数据的策略，从而实现业务数据的零丢失目标。交易状态表用来识别备份数据库归档日志已恢复了哪些成功提交的事务[8]。

交易同步报文缓冲池实际上是一个先进先出交易同步报文存储区，简称FIFO缓冲区，用以保存事务处理系统近期产生的交易数据或称交易重做日志。主备系统两端各维持一个交易同步报文缓冲池，以满足不同工作模式下的报文同步需求。

同步管理程序由同步通信程序、缓冲池管理程序等组成。同步通信程序负责两地系统之间的交易同步报文的封装与传输，缓冲池管理程序负责管理FIFO缓冲区，定时判别备份数据库中归档日志的恢复状态，清除缓冲池内过时的交易同步报文。

3.3 交易报文的分解规则

规则1：针对批量交易事务，设T为原始交易报文，i为当前交易识别序号，n为T中包含的面向数据库的事务对象数量。若n>1，则多个事务对象依次序拆分成多个交易同步报文，即{Ti，Ti+1,…,Ti+n-1}。

规则2：针对联机会话事务，多个交易报文对应一个数据库事务对象，则标记事务起始报文及事务结束报文，以会话识别号为关联值，识别整体事务对象。标示为：Tb为会话起始报文，Te为会话结束报文，k为会话识别号，交易同步报文子集{Ti.SessionID=k，i=b,b+1,b+2,…,e}被识别为整体事务。

规则3：针对文件收发事务，建立事务起始报文及事务结束报文。识别文件对象收发的完整性，支持大文件断点续传。

3.4 交易报文同步的工作模式

为满足特定的业务需求，交易报文同步系统设计为多种工作模式，各模式工作方式,如表3所示。

表3 交易报文同步系统的工作模式

最高一致性模式下，主系统交易报文层的应用程序必须确认交易同步报文写入本地及异地的FIFO缓冲区后，再将交易报文交付后续应用程序处理。此时，若数据同步线路故障，则该应用程序挂起，不再继续工作，直至故障恢复或同步工作模式切换。这种模式可保持两地系统最高的事务数据一致性。

最高可用性模式下，主系统交易报文层的应用程序将交易同步报文写入本地FIFO缓冲区后，交易报文随即交付后续应用程序处理。同步管理程序以后台任务方式将本地FIFO缓冲区的交易同步报文传递到对端系统，或称异步模式。此时若数据同步线路故障，主系统业务处理流程不受影响。这种模式符合生产系统绝对优先原则，任何备份措施的故障不应该造成生产系统的停顿。

自动管理模式在同步线路故障时事务处理流程有短暂的延时，延时时间取决于两地交易报文同步系统之间设定的健康检查条件。一般情形下，设定单位时间内数次获取不到对端系统的正常应答信息，则判定通信故障。自动管理模式体现了备份措施能用则用，但备份措施故障时业务系统还得继续工作的原则。这个模式也是应用实践中的推荐模式。

4 实验与分析

实验数据源自于特大型城市的公共交通一卡通支付清算业务系统。实验环境由该系统的原型测试系统组成，主系统及备系统各由二台HPUX小型机及一台HP XP20000存储构成，其中一台小型机部署Oracle数据库系统，另一台部署清算业务应用系统。二台小型机及存储系统具备较高配置，满足每秒处理800笔业务交易的能力。

为了便于实验环境的搭建及各种实验条件的控制，主备系统均位于同一机房。两个系统之间采用专属以太网线路连接，并通过以太网接口速率的协商控制，满足千兆、百兆及十兆等数据同步线路带宽的实验条件。

测试数据库表空间基础容量2 TB左右，沉淀3年以上的业务数据。每个在线日志200 MB。6 000万笔测试业务数据来自实际生产系统3至4个交易日业务数据的积累。实验环境下测试辅助程序通过读取交易累积目录下的业务数据文件形成原始交易报文直接交付给应用系统的前置通信程序。

实验共分三轮，每轮使用2 000万笔交易业务测试数据。

第一轮测试采用数据库在线日志实时同步方式，实验观察该方式下对系统性能的影响及网络带宽的要求。该轮实验主备数据库运行在Oracle Dataguard最大保障模式下(无数据丢失)，主备系统之间网络带宽千兆。2 000万笔交易处理用了近30个小时，平均每秒处理约200笔交易。鉴于这个结果，更低带宽的同步条件已无测试必要。

第二轮测试采用数据库归档日志异步传输方式及交易报文实时同步方式。实验观察该方式下对系统性能的影响及网络带宽的要求。该轮实验主备数据库运行在Oracle Dataguard最大性能模式，应用层交易报文同步系统工作在最高一致性模式。主备系统之间网络带宽按预估带宽百兆设定。2 000万笔交易处理用了约8个小时，平均每秒处理约700笔，该性能达到单系统峰值处理能力的87.5%，已满足异地容灾备份的预定技术要求。

第三轮测试与第二轮测试工作方式基本一样。但本轮实验应用层交易报文同步系统工作在自动管理模式。实验观察该方式下网络带宽对数据同步状态的影响及业务数据的恢复能力。测试情况如表4所示。

表4 各阶段网络带宽及系统同步状态

本轮最后阶段结束后(主系统处理完2 000万笔交易)，中断二个系统之间的网络连接，此时，备系统仅恢复到已传输完成的归档日志。将备份数据库激活，应用层交易报文重做恢复机制介入，备系统的交易报文同步管理程序通过比较备库的交易状态表与备系统交易同步报文缓冲池的相关报文信息，将差额交易数据从备系统交易报文同步缓冲区中提取并交付备系统应用程序处理，适时恢复备系统的业务数据。差额交易共用时30分钟，处理150万笔交易。最后，通过主备两个数据库系统一卡通账务表，交易明细表，业务清算表等对比，主备系统业务数据完全一致。

实验表明，本文方法有效，并具有较高的宽容度，在极低的同步线路带宽下仍能稳定工作，高达百万笔的业务交易差异能有效识别并适时恢复，恢复后的事务处理系统业务数据一致性和完整性能切实保障。

5 容灾备份中的实际应用

上海与北京两个特大型城市的公共交通一卡通支付系统，日均业务量均在2 000万笔左右，地铁、公交、出租等公共交通支付服务事关民生与社会稳定，建立异地容灾备份系统刻不容缓。2004年上海一卡通系统率先采用应用级的交易报文同步技术，实现同城异地的容灾备份。2007年北京一卡通系统采用改进后的交易报文同步技术，也建立了同城异地的容灾备份体系。两大异地容灾备份系统均采用百兆以太网的数据同步线路，数据库归档日志日均产生量100 GB左右，数据库系统在百兆网络条件下以最大性能模式异步传输归档日志。一卡通支付业务系统平均每笔交易长度控制在150 B，交易报文日均产生量低于3 GB。交易报文数据实时同步在百兆以太网线路条件下对实际应用系统性能的影响低至忽略不计。主数据同步线路故障时，仅2 Mbps带宽的数据同步备份线路的条件下，数据库归档日志传递已处于卡顿状态，基于交易报文的数据同步方法还能正常工作，此时一旦灾难发生，异地系统仍可依赖应用级的交易报文重做机制保障业务数据的完整性。二大系统经历了2008年奥运及2010年世博会期间大业务量的考验，十余年来稳定运行，基于应用层的交易报文同步技术不断改进、日趋成熟，逐渐形成了目前完整的、可重用的数据同步应用体系。

实际上，本地备份数据库的恢复过程也可以通过应用程序重做本地缓冲池内的交易报文，实现业务数据的完整恢复，进一步增强应用系统自身结构上的业务恢复能力。

6 结 语

本文给出的基于交易报文的数据实时同步方法，将事务处理系统的交易报文归纳为应用级的重做日志，结合数据库的归档日志恢复机制，在大业务量的应用系统中，无需高成本、高带宽的数据同步线路，即可实现异地备份系统业务数据的完整性与一致性。经实际案例的测试与分析，该方法的可行性、有效性得到了充分验证。该方法在特定事务处理系统的异地容灾备份实践中具有较强的可操作性和实用价值。

[1] 陈文捷，蔡立志．大数据安全及其评估[J]．计算机应用与软件，2016，33(4)：34-38，71．

[2] 杨天明，吴海涛．一种批处理块级数据去重方法[J]．计算机应用与软件，2016，33(5)：44-46，60．

[3] 冯凌颖，陈耀武，蒋荣欣．一种异构主从模式数据同步园区停车系统的设计与实现[J]．计算机应用与软件，2016，33(4)：64-67，75．

[4] 张泽鑫，李俊，常向青. 互联网流量的演化研究[J]. 计算机应用与研究，2015，32(11):3215-3221.

[5] 丁建立，王斌强，张超．异地双活数据中心服务区域划分优化[J]．计算机应用与软件，2016，33(2)：30-32，54．

[6] 王晨光，王静，张超，等．面向航空物流的数据交换平台设计方法研究[J]．计算机应用与软件，2015，32(12)：34-37．

[7] 郝平，林原冲．一种移动网络下基于双时间戳的数据增量同步研究[J]．计算机应用与软件，2016，33(4)：143-145，226．

[8] 王德军，何征，王丽娜. 基于事件的连续数据保护系统研究[J].计算机应用研究，2014,31(2):465-471，475.

RESEARCHONREAL-TIMEDATASYNCHRONOUSMETHOD
BASEDONTRANSACTIONMESSAGE

Shang Hai Ying

(ShanghaiJiuyuSoftwareSystemCo.,Ltd.,Shanghai200233,China)

This paper presents the common methods of remote data synchronization in computer information system. Under the large volume business scene of a transaction processing system, traditional data replication technology is limited by high network bandwidth. Therefore, we propose a real-time data synchronization method based on transaction message. The transaction messages of transaction processing system were classified as application level message redo logs, and the methods and strategies of packet decomposition and encapsulation, message synchronization and buffer pool management were adopted. Finally, the real-time synchronization target of business data was realized with very low line bandwidth. Through the implementation of disaster recovery case practice, we fully verified the feasibility and effectiveness of the method. The proposed method can significantly reduce the implementation cost of application-level disaster recovery in large traffic.

Transaction processing system Disaster recovery Redo log Data replication Recovery point objective

2017-06-09。尚海鹰，工程师，主研领域：事务处理系统，系统集成，数据库管理。

TP3

A

10.3969/j.issn.1000-386x.2017.11.025