海洋

（中國鐵路信息技術(shù)中心，北京 100844）

數(shù)據(jù)復(fù)制技術(shù)在鐵路電子支付平臺中的應(yīng)用

海洋

（中國鐵路信息技術(shù)中心，北京 100844）

分析基于存儲復(fù)制、基于邏輯卷（LV）復(fù)制、基于文件復(fù)制和基于事務(wù)復(fù)制等的數(shù)據(jù)復(fù)制技術(shù)及其優(yōu)缺點。針對數(shù)據(jù)復(fù)制技術(shù)的選擇進行調(diào)研和測試，選擇采用SharePlex數(shù)據(jù)復(fù)制軟件。分析SharePlex數(shù)據(jù)復(fù)制軟件特點，從數(shù)據(jù)捕獲、數(shù)據(jù)傳輸和數(shù)據(jù)應(yīng)用方面論述數(shù)據(jù)復(fù)制過程。闡述和分析SharePlex數(shù)據(jù)復(fù)制軟件在鐵路電子支付平臺數(shù)據(jù)容災(zāi)中的應(yīng)用，為驗證鐵路電子支付平臺數(shù)據(jù)庫容災(zāi)系統(tǒng)的有效性，對其數(shù)據(jù)庫容災(zāi)系統(tǒng)進行正反向切換演練。

數(shù)據(jù)復(fù)制技術(shù)；鐵路；電子支付平臺；鐵路客票；數(shù)據(jù)庫容災(zāi)

0 引言

鐵路電子支付平臺自2011年1月正式上線運行，6年來其支持的交易種類不斷增加，目前基于客運支付的互聯(lián)網(wǎng)交易、手機WAP交易、POS交易、TVM交易、閘機交易、卡務(wù)交易的應(yīng)用已進入平穩(wěn)運行階段。鐵路電子支付平臺的應(yīng)用，標(biāo)志著鐵路客票銷售方式進入了一個新階段[1]。這種新的售票方式很快被大眾接受，其中互聯(lián)網(wǎng)交易和手機交易成為出行買票的首選方式。隨著時間的推移，通過12306網(wǎng)站和手機客戶端售出的車票呈現(xiàn)快速增長趨勢，目前每天超過500萬張，占每天全路客票銷售量的60%以上。Oracle作為數(shù)據(jù)庫系統(tǒng)中的核心組成部分，存儲了所有的實時交易信息和銀行對賬信息，一旦其出現(xiàn)故障且不能盡快恢復(fù)，將導(dǎo)致電子支付平臺無法正常運行，影響旅客購票和出行，造成不良的社會輿論影響[2]。因此，數(shù)據(jù)庫的安全運行至關(guān)重要。由于傳統(tǒng)的數(shù)據(jù)庫備份恢復(fù)機制無法做到實時備份和恢復(fù)，恢復(fù)點目標(biāo)（RPO）和恢復(fù)時間目標(biāo)（RTO）不易控制，并存在數(shù)據(jù)丟失的可能性，因此無法滿足數(shù)據(jù)庫系統(tǒng)的高可靠性要求。引入數(shù)據(jù)容災(zāi)系統(tǒng)有以下作用：實現(xiàn)數(shù)據(jù)級的容災(zāi)，實現(xiàn)生產(chǎn)數(shù)據(jù)庫和容災(zāi)數(shù)據(jù)庫的實時同步；將容災(zāi)數(shù)據(jù)庫設(shè)置為打開狀態(tài)，為應(yīng)用提供查詢和報表生成業(yè)務(wù)，分擔(dān)生產(chǎn)數(shù)據(jù)庫的壓力；可保證RPO＜1 min，RTO＜5 min；支持?jǐn)?shù)據(jù)的雙向復(fù)制；實現(xiàn)快速、安全的正向和反向切換。數(shù)據(jù)容災(zāi)系統(tǒng)提高了數(shù)據(jù)的可靠性、應(yīng)用的連續(xù)性和數(shù)據(jù)庫的可用性，保證了數(shù)據(jù)庫的安全運行。

1 常見數(shù)據(jù)復(fù)制技術(shù)

數(shù)據(jù)容災(zāi)基于數(shù)據(jù)復(fù)制技術(shù)實現(xiàn)，數(shù)據(jù)復(fù)制是使用復(fù)制軟件將源端的數(shù)據(jù)從一個服務(wù)器（或存儲）實時地傳輸?shù)侥繕?biāo)端另一個服務(wù)器（或存儲），這樣相當(dāng)于對源端的數(shù)據(jù)進行了鏡像，進而達到容災(zāi)的目的。因復(fù)制啟動時機不同，數(shù)據(jù)復(fù)制可分為異步復(fù)制和同步復(fù)制。異步復(fù)制必須等待目標(biāo)端返回確認(rèn)信號后才可進行實時復(fù)制；同步復(fù)制無需等待目標(biāo)端返回確認(rèn)信號即可進行實時復(fù)制。根據(jù)不同的復(fù)制對象以及復(fù)制對象所處的層級，數(shù)據(jù)復(fù)制可分為基于存儲復(fù)制、基于邏輯卷（LV）復(fù)制、基于文件復(fù)制、基于事務(wù)復(fù)制。

1.1 基于存儲復(fù)制

基于存儲復(fù)制通常采用同步復(fù)制技術(shù)，復(fù)制對象為存儲中的變化塊（block），相當(dāng)于對存儲做鏡像。其優(yōu)點是實施簡單、復(fù)制速度快、對服務(wù)器影響小、日常維護管理方便易行；缺點是復(fù)制時無論好塊或壞塊均進行復(fù)制，且目標(biāo)端數(shù)據(jù)庫必須處于CLOSE狀態(tài)，不能驗證目標(biāo)端數(shù)據(jù)庫與源端數(shù)據(jù)庫的一致性。因此，當(dāng)生產(chǎn)數(shù)據(jù)庫發(fā)生故障需要切換到容災(zāi)數(shù)據(jù)庫時，很可能發(fā)生容災(zāi)數(shù)據(jù)庫無法啟動狀況。基于存儲復(fù)制一般是作為數(shù)據(jù)容災(zāi)的補充手段。

1.2 基于邏輯卷（LV）復(fù)制

基于邏輯卷（LV）復(fù)制一般采用同步復(fù)制技術(shù)，復(fù)制對象為LV中的變化塊，相當(dāng)于對LV做鏡像。其對系統(tǒng)的I/O影響較大，并與基于存儲復(fù)制一樣，復(fù)制時無論好塊或壞塊均進行復(fù)制，且目標(biāo)端數(shù)據(jù)庫必須處于CLOSE狀態(tài)，不能驗證目標(biāo)端數(shù)據(jù)庫與源端數(shù)據(jù)庫的一致性。因此，當(dāng)生產(chǎn)數(shù)據(jù)庫發(fā)生故障需要切換到容災(zāi)數(shù)據(jù)庫時，很可能發(fā)生容災(zāi)數(shù)據(jù)庫無法啟動狀況。大型數(shù)據(jù)庫的容災(zāi)很少采用基于邏輯卷（LV）復(fù)制。

1.3 基于文件復(fù)制

基于文件復(fù)制一般采用異步復(fù)制技術(shù)，復(fù)制對象為文件系統(tǒng)中的文件I/O。復(fù)制過程是在源端捕獲應(yīng)用文件的I/O，并緩存起來，等緩存達到一定量時，通過傳輸隊列傳輸?shù)侥繕?biāo)端，再寫入目標(biāo)端存儲，完成一次復(fù)制，相當(dāng)于對文件的拷貝。其缺點是復(fù)制時無論好塊或壞塊均進行復(fù)制，且目標(biāo)端數(shù)據(jù)庫必須處于CLOSE狀態(tài)，不能驗證目標(biāo)端數(shù)據(jù)庫與源端數(shù)據(jù)庫的一致性。因此，當(dāng)生產(chǎn)數(shù)據(jù)庫發(fā)生故障需要切換到容災(zāi)數(shù)據(jù)庫時，很可能發(fā)生容災(zāi)數(shù)據(jù)庫無法啟動狀況。

1.4 基于事務(wù)復(fù)制

基于事務(wù)復(fù)制通常采用異步復(fù)制技術(shù)，復(fù)制對象為數(shù)據(jù)庫中的變化數(shù)據(jù)。復(fù)制過程是源端的捕獲進程通過解析源端數(shù)據(jù)庫Redo Log和Archive Log找到變化的數(shù)據(jù)，然后捕獲進程把變化的數(shù)據(jù)放到傳輸隊列中，再經(jīng)由傳輸進程發(fā)送到目標(biāo)端，目標(biāo)端的接收進程把收到的數(shù)據(jù)寫入目標(biāo)端隊列，加載進程按照事物的邏輯順序?qū)邮盏降臄?shù)據(jù)進行排序，最后把數(shù)據(jù)加載到目標(biāo)數(shù)據(jù)庫中?；谑聞?wù)復(fù)制可保證源端和目標(biāo)端數(shù)據(jù)庫數(shù)據(jù)的一致性，同時目標(biāo)端數(shù)據(jù)庫處于正常OPEN狀態(tài)。當(dāng)源端的生產(chǎn)數(shù)據(jù)庫發(fā)生故障無法對外提供服務(wù)時，可直接使用目標(biāo)端的數(shù)據(jù)庫恢復(fù)業(yè)務(wù)，RTO接近于零?；诖鎯?fù)制、基于邏輯卷（LV）復(fù)制、基于文件復(fù)制和基于事務(wù)復(fù)制技術(shù)的對比見表1。

表1 基于存儲復(fù)制、基于邏輯卷（LV）復(fù)制、基于文件復(fù)制和基于事務(wù)復(fù)制技術(shù)的對比

綜上所述，基于事務(wù)復(fù)制可最大程度保證事務(wù)的一致性，源端和目標(biāo)端的數(shù)據(jù)庫同時可用，是現(xiàn)今最常采用的數(shù)據(jù)復(fù)制技術(shù)之一。

2 數(shù)據(jù)復(fù)制軟件選擇

在選擇數(shù)據(jù)庫容災(zāi)系統(tǒng)時進行了大量調(diào)研和測試，最終選擇采用美國Dell股份有限公司的SharePlex數(shù)據(jù)復(fù)制軟件，其邏輯結(jié)構(gòu)見圖1。SharePlex數(shù)據(jù)復(fù)制軟件對網(wǎng)絡(luò)帶寬要求低，可跨不同操作系統(tǒng)平臺和不同Oracle版本的Oracle數(shù)據(jù)庫，實時復(fù)制速度快，可滿足用戶對應(yīng)用和數(shù)據(jù)庫的高可用性、災(zāi)難恢復(fù)、生產(chǎn)與報表分離等要求，安裝配置和日常維護簡單易行，售后服務(wù)及時完善。與其他主流的數(shù)據(jù)庫復(fù)制產(chǎn)品相比，SharePlex數(shù)據(jù)復(fù)制軟件特點如下。

圖1 SharePlex數(shù)據(jù)復(fù)制軟件邏輯結(jié)構(gòu)

（1）對數(shù)據(jù)庫無侵入性，采用基于讀取Oracle日志的邏輯復(fù)制方式，支持9i以上所有數(shù)據(jù)庫版本，不需要查詢Oracle數(shù)據(jù)庫中數(shù)據(jù)。

（2）不需要在生產(chǎn)數(shù)據(jù)庫創(chuàng)建觸發(fā)器即可支持絕大部分DDL操作的復(fù)制，所有DDL操作均從日志中捕捉。

（3）支持目標(biāo)端的表增加記錄額外信息的列，包括操作類型（Insert/Update/Delete）、操作時間、SCN、RowID、事務(wù)ID、事務(wù)順序號、源端代碼等。

（4）支持對源端事務(wù)的選擇性復(fù)制，既可指定源端的某個事務(wù)不被復(fù)制到目標(biāo)端，也可指定源端某個用戶的所有DML、DDL操作不被復(fù)制到目標(biāo)端。

（5）具有復(fù)制過程中自動校驗功能，當(dāng)出現(xiàn)數(shù)據(jù)不一致情況時，復(fù)制軟件可選擇停止復(fù)制或記錄不一致數(shù)據(jù)后繼續(xù)復(fù)制，并發(fā)出報警信息。

（6）可保證目標(biāo)端事務(wù)與源端的一致性，不會對生產(chǎn)系統(tǒng)產(chǎn)生的事務(wù)進行拆分或合并。

（7）支持所有常見的各種共享文件系統(tǒng)，包括Oracle的自動存儲管理（ASM）。

（8）支持所有的Oracle數(shù)據(jù)類型，包括Bfile、XML等。

（9）支持特殊表名，如以數(shù)字開頭或大小寫敏感的表名。

（10）復(fù)制是在事務(wù)開始后進行，無論復(fù)制大事務(wù)或小事務(wù)，可確保數(shù)據(jù)的實時性，所有事務(wù)與源端完全一致。

（11）從容災(zāi)端向生產(chǎn)端回切時，業(yè)務(wù)系統(tǒng)可快速反向回切，不需要對恢復(fù)正常的生產(chǎn)數(shù)據(jù)庫進行數(shù)據(jù)全同步或重新部署復(fù)制軟件，僅需將容災(zāi)數(shù)據(jù)庫中的增量數(shù)據(jù)回寫到生產(chǎn)數(shù)據(jù)庫中即可完成生產(chǎn)數(shù)據(jù)庫的恢復(fù)工作。

（12）數(shù)據(jù)的復(fù)制粒度靈活多樣，可通過用戶級、表級、列級過濾、表級過濾實現(xiàn)數(shù)據(jù)庫容災(zāi)、報表、數(shù)據(jù)隱藏、分發(fā)等。在復(fù)制模式上，支持單向復(fù)制、雙向復(fù)制、廣播復(fù)制、合并復(fù)制等。

數(shù)據(jù)復(fù)制過程主要包括以下三方面：一是數(shù)據(jù)捕獲（Capture&Read）。捕獲進程位于源端，通過讀取數(shù)據(jù)庫Redo Log和Archive Log中的信息獲取變化的數(shù)據(jù)，并將其放到傳輸隊列中。由于是從數(shù)據(jù)庫的日志文件中獲取信息，因此捕獲進程不會對數(shù)據(jù)庫的性能產(chǎn)生影響。假如捕獲進程由于某些原因宕掉，重新啟動后復(fù)制不會受到影響。二是數(shù)據(jù)傳輸（Export&Import）。傳輸進程是使用復(fù)制技術(shù)本身的協(xié)議和TCP/IP協(xié)議將傳輸隊列中的數(shù)據(jù)發(fā)送到目標(biāo)端，同時可保證傳輸過程中數(shù)據(jù)包的順序是正確的，并確保目標(biāo)端正確接收數(shù)據(jù)，如果傳輸?shù)臄?shù)據(jù)量過大，可分成多個傳輸隊列進行傳輸。三是數(shù)據(jù)應(yīng)用（Post）。應(yīng)用進程從傳輸隊列中取出數(shù)據(jù)并轉(zhuǎn)化為SQL語句，再提交到數(shù)據(jù)庫中執(zhí)行。

3 SharePlex數(shù)據(jù)復(fù)制軟件在鐵路電子支付平臺數(shù)據(jù)容災(zāi)中的應(yīng)用

鐵路電子支付平臺使用的數(shù)據(jù)庫版本是Oracle 11G，并采用RAC架構(gòu)提高數(shù)據(jù)庫的可靠性。生產(chǎn)數(shù)據(jù)庫按業(yè)務(wù)類型分為交易數(shù)據(jù)庫和對賬數(shù)據(jù)庫。交易數(shù)據(jù)庫主要承擔(dān)售票、退票等支付業(yè)務(wù)，對賬數(shù)據(jù)庫主要承擔(dān)交易記錄查詢、銀行對賬、月/季/年報表生成等查詢和管理業(yè)務(wù)。容災(zāi)數(shù)據(jù)庫與生產(chǎn)數(shù)據(jù)庫采用相同的架構(gòu)。生產(chǎn)數(shù)據(jù)庫與容災(zāi)數(shù)據(jù)庫之間的數(shù)據(jù)同步由數(shù)據(jù)復(fù)制軟件完成。同時為交易數(shù)據(jù)庫與對賬數(shù)據(jù)庫中的一些數(shù)據(jù)量很大的表，建立單獨的傳輸隊列，以保證數(shù)據(jù)復(fù)制的速度。數(shù)據(jù)庫容災(zāi)系統(tǒng)自2014年初建成運用以來，運行平穩(wěn)、復(fù)制延遲小、速度快，基本實現(xiàn)了數(shù)據(jù)的實時復(fù)制，日常維護簡單易行，達到設(shè)計目的，保證了數(shù)據(jù)的安全[3]。數(shù)據(jù)庫容災(zāi)系統(tǒng)架構(gòu)見圖2。

圖2 數(shù)據(jù)庫容災(zāi)系統(tǒng)架構(gòu)

4 數(shù)據(jù)庫容災(zāi)系統(tǒng)切換演練

2014年10月28日和30日，鐵路電子支付平臺數(shù)據(jù)庫容災(zāi)系統(tǒng)進行了正向和反向切換演練，其數(shù)據(jù)復(fù)制軟件的切換時間不到5 min，極大壓縮了系統(tǒng)整體的切換時間。數(shù)據(jù)庫容災(zāi)系統(tǒng)在10月28—29日承擔(dān)了實際的電子支付交易業(yè)務(wù)，其運行狀態(tài)良好，未出現(xiàn)因數(shù)據(jù)庫容災(zāi)系統(tǒng)處理能力不足導(dǎo)致業(yè)務(wù)響應(yīng)慢等問題，保證了鐵路售票系統(tǒng)的安全。

[1] 李天翼，王明哲，王芳. 鐵路客票系統(tǒng)電子支付關(guān)鍵技術(shù)的研究[J]. 中國鐵路，2012(6)：51-55.

[2] 祝詠升，姚洪磊. 鐵路客票系統(tǒng)信息安全保障平臺測評體系研究[J]. 中國鐵路，2013(10)：70-72.

[3] 姚洪磊，李紅建，張彥，等. 鐵路客運服務(wù)系統(tǒng)信息安全測試方法研究[J]. 鐵路計算機應(yīng)用，2013，22(3)：1-4.

Application of Data Replication Technologies in Railway Electronic Payment Platform

HAI Yang
（China Railway Information Technology Center，Beijing 100844，China）

This paper analyzes data replication technologies based on storage replication, logical volume (LV) replication, file replication and transaction replication, and their advantages and disadvantages. For choosing data replication technologies, researches and tests are carried out, and SharePlex data replication software is chosen and used. The paper analyzes the characteristics of the software and the data replication process from data capturing, data transmission, and data application. It also describes and analyzes the application of SharePlex data replication software in the data disaster tolerance of railway electronic payment platform. In order to verify the effectiveness of the disaster tolerance system of railway electronic payment platform database, forward and reverse switches of the system are carried out.

data replication technologies；railway；electronic payment platform；railway passenger ticket；database disaster tolerance

U26；TP277

A

1001-683X（2017）03-0088-04

10.19549/j.issn.1001-683x.2017.03.088

苑曉蒙

2017-01-02

海洋（1975—），男，工程師。E-mail：haiyang@sinorail.com