DTCC 乾貨 | 中國銀聯跨中心，異構資料同步技術與實踐

作者：翁海星  編輯：張曉藝

摘要：Moray 是中國銀聯為支援應用的異地多活、異構資料庫的資料同步而設計的元件。本次將分享中國銀聯實現跨資料中心、高效能、可異構化的實時資料同步技術，以及 Moray 在中國銀聯異地多活系統中的實踐經驗。

翁海星，中國銀聯異構&異地資料同步專案 Moray 負責人，從事資料庫核心研發工作，主要關注儲存引擎、資料複製。

本文根據翁海星老師在DTCC資料庫大會分享內容整理而成，將介紹中國銀聯實現跨資料中心、高效能、可異構化的實時資料同步技術，以及 Moray 在中國銀聯異地多活系統中的實踐經驗。

 1   需求背景

1.1 資料同步 

資料同步（也可以說資料複製或者資料傳輸）在一些特定的場景中是非常重要的，比如說業務系統的災備部署：為了應對某個業務中心不可服務的情況，資料需要及時同步到另一箇中心以完成業務切換；在實際的應用場景中，兩個城市的業務中心可能會各自承擔部分流量，雙活的架構對資料實時同步的要求就比較高。

從2012年開始，中國銀聯在技術上確定了比較重要的方向：去IOE和多活建設。在這之前中國銀聯的傳統業務資料都部署在DB2上，由2012年起，逐漸遷移到開源資料庫或者國產資料庫之上，如圖【1】中的UPSQL就是中國銀聯在MySQL上的定製資料庫版本（相信大家都可以通過“UP”聯想到）。

同時，目前銀聯在上海、北京各有一個資訊中心，銀聯也正有計劃地將業務系統進行多活改造。傳統的金融企業去做國產資料庫或者是自研開源資料庫的原因無非三點：

第一個是前段時間去IOE的“風氣”，這裡麵包含政策激勵和技術導向，金融行業或多或少地會去開始接觸這類工作，同樣也是得益於去IOE之風，我們的國產資料庫和開源資料庫才能蓬勃發展；

第二個是商業資料庫維護的成本問題；

第三個是商業資料庫有時的確無法負載實際的業務發展規模,以銀聯雲閃付為例，在有優惠或者是折扣之類的活動時，系統處理業務時會存在熱點賬戶，在做大促活動的實踐中，銀聯已經發現DB2的熱點更新是存在問題的，可以察覺到明顯的時延（熱點賬戶更新問題也是我們今年的一個主要的工作）。

在以上的背景下，我們發現這些工作從開發到運維，每一步都充滿了挑戰，這裡主要分享一下銀聯在資料同步上做的工作。

假設我們有兩個業務，放在兩個機房或者兩個中心，在做業務災備或者多活的時候需要搭建資料同步，最簡單的一個方案肯定是MySQL的原生複製。複製的原理，簡單來說，就是主庫在事務提交的時候會寫binlog，從庫獲取主庫上的binlog並寫到自己的中繼日誌（relaylog）中，再回放relaylog中的事務。

MySQL的複製其實是做得比較完善的，它除了提供單向的主從複製之外，還可以雙向地做主主複製，使得在做業務雙活的時候，兩邊都可以得到資料的同步。

MySQL在5.7之後還提供了半同步複製，相對於非同步複製，能保證主庫在提交事務之前確認從庫收到日誌並落盤，可以很大程度上確保資料一致。銀聯在做一些系統雙活的時候，在實際業務場景中，會發現它的原生複製其實有很大限制。

下面看一個比較複雜的場景，這裡會有一個新朋友叫proxy。實際業務場景裡銀聯的資料體量是非常大的。拿銀聯無卡系統來舉例，每天生成的交易量均過千萬，單一的MySQL是無法支撐這樣規模的資料量的。

為了實現部署資料庫叢集，銀聯自主研發了中介軟體UPSQL-Proxy，實現了自動的分庫分表、SQL路由、自動擴縮容以及資料庫高可用，時至今日，這個技術路線已經發展成了分散式資料庫叫UPDRDB。銀聯的DRDB通過自主研發的MySQL 儲存引擎外掛，協調整個資料庫叢集，給使用者提供像單機MySQL一樣的體驗。

現在來看一下整個業務中心的場景。上海中心的每個資料分片都分一個主從，然後主從去做半同步複製來確保它的高可用。

但此時就會出現這樣一個問題，兩個中心之間的複製該怎樣同步？最直觀的就是從資料庫拉一條複製鏈路，這個其實是有問題的。因為這樣做對於MySQL來說，其實就是一個多源複製鏈路，即其中某個分片的relaylog是從多個資料來源獲取。

MySQL的多源複製是不支援半同步複製的，這樣它就不能保證高可用。另外，上海中心和北京中心的資源本身是不一樣的。可能北京中心拿不出那麼多的物理資源，比如說上線一個系統，上海中心出50個CG，北京中心就只能出25。如果在這上面去搭建複製方向就不太好去維護。這個是銀聯遇到的第一個問題。

再來的問題是異構資料之間的同步：

一、在做業務系統的時候不僅用到資料庫，而且還用到快取。在做活動的時候，經常會把一些促銷資訊或者使用者積分放到快取裡面，應用再從快取裡去讀寫。當然這些資料不會一直放在快取裡面，還需要落地到資料庫；

二、從DB2遷移系統的時候，肯定會有兩個地方用到異構資料的同步，DB2存量的資料遷移，以及上線之後的並行測試，兩個資料庫都需要承擔部分流量。

更復雜的情況是也是需求帶來的。做過業務的人應該會比較清楚，大部分業務系統的聯機庫都會往彙總庫同步資料。

很多銀行的做法就是T+1去跑批，然後把它放到彙總庫中，此時會有更“豐富”的要求，如：聯機的業務日誌或者是流水只需要往彙總庫去寫，交易中的狀態只需要記錄成功或者失敗，還有把交易中的記錄按照日期來做分表，甚至把某些欄位給過濾掉或改掉，也就是資料的形變和過濾，這些都要求即時完成。

銀聯在做這個事情之前，也調查過很多其他的工具或者是開源元件，但是一直沒有找到合適的，所以去年開始決定自己來研發資料同步元件，實現前面說的那些複雜的需求。這個元件就是我們自己研發的Moray。

簡單來說，Moray就是一個資料的同步元件，它是為資料庫提供點對點和準實時的資料同步的服務，這裡面的資料庫不僅僅是指UPSQL，也有DRDB、Proxy和Redis，還有一些其它的異構資料庫。它的原理有些類似ETL，就是獲取資料去進行傳輸和加工，再進行回放的過程。

在設計Moray的時候，主要考慮到三個要點：

對應用透明，應用不需要去感知Moray的，它只需要在上層把自己的業務做好，實際資料同步不需要它去關心。

應用無需額外開發，比如之前提及的既要寫Redis又要寫快取，這個是不需要去關心的。

儘量降低對主庫效能的影響。我們在設計的時候儘量去解析資料庫日誌，比如UPSQL就去解析binlog，針對Redis我們去解析EOF日誌，去儘量降低對主庫效能影響。

2   架構設計

2.1 前後端分離

上圖是在Moray的元件設計框架。考慮到之後業務的發展可能會有更多的、更新的資料端給加進來，所以說在考慮設計Moray的時候，是把它一分為二來看的。

Moray分為前端模組和後端外掛兩部分，這個設計很簡潔，前端就是一個生產者，它從資料來源抽取資料，通過設計的內部通用協議，把資料流傳給後端的外掛處理。

後端是使用熱插拔外掛的方式來實現的，Moray提供標準的四個介面。在做新的資料流同步的時候，可以很輕鬆地寫一個新的外掛，主要實現四個介面：外掛初始化函式，外掛銷燬函式，將資料包寫入目的端資料庫的處理函式，以及處理完成的回撥介面，實現完這四個函式之後，就可以把外掛加入到Moray程式，實現異構資料庫的同步。

整個Moray架構是比較靈活和多變的，可以很好的支援不同資料來源和目標資料庫的組合。

目前前端模組可以處理的資料來源為DB2、UPSQL（Proxy）、Redis以及遠端模組，UPSQL前端處理Binlog，Redis前端解析AOF日誌，DB2前端由於日誌的協議未開放，因此是通過時間片掃描的方法獲取增量資料，遠端模組是較特殊的前端，用於接收異地Moray傳送的資料。

後面的外掛可以將同步的資料寫入DB2、Redis、ES及其他大資料平臺，Remote外掛與遠端前端模組配合，將資料流發給異地的moray元件。

2.2 設計要點

以下是銀聯在設計上考慮得比較多的地方。

事務性

第一個我們比較看重的一點，Moray在資料同步的時候，解析階段和回放階段都要保證資料回放的事務性。資料在主庫中的事務如何提交，在回放的時候，這些資料肯定也要到一個事務裡面去。因為我們不希望另一個業務中心讀到髒的資料，這個是通過設計內部的協議格式來做的。

高安全

還有在做跨中心資料同步的時候，要保證資料是安全、不丟失的。Moray在設計上具有斷點續傳功能。如果Moray出故障down掉了或者因為其它需求需要遷移環境，只需要重新拉一個程式，就可以從上一次同步的進度開始繼續進行；異地中心報文還做了校驗，防止資料篡改。

高效能

Moray在資料同步時儘量保證資料庫不受影響，儘可能地不直接讀源表，不去和應用競爭資料庫的資源（解析binlog或者AOFlog）;在做資料同步的時候，對資料做壓縮傳輸;使用多執行緒並行回放，尤其對於UPSQL，參考了MySQL8.0的回放的演算法。

高可用

Moray作為輕量級元件，採用的是端到端同步的方法。各個業務之間的Moray程式是獨立執行的，降低了它和源庫的耦合度，也可以靈活部署，並通過銀聯的資料元件排程平臺（DBASS）實現高可用。

高可管理

這裡指與Moray搭配的一個監控平臺。在平臺上可以很方便的建立起Moray的資料同步流向。並通過監控平臺我們可以看到Moray的同步狀態、健康狀況以及資料時延。

容錯

我們還考慮到一些容錯的場景，比如說在資料回放的時候，可能會遇到insert資料已經存在，或者update的記錄不存在的一些場景，Moray支援對此類問題的自動容錯。另外在做資料追補的時候（時間點回撥），Moray可以過濾掉已經執行過的事務，這個是通過資料庫的GTID的機制來做的。

外掛化

外掛化，Moray的模組和外掛都是易於擴充套件的，未來可以實現更多資料庫的異構同步。

非同步化

要保證高效能的比較重要的一點是要非同步化。前端模組傳輸資料給後端、後端寫入資料到目的庫，都是通過非同步方式實現的。

2.3 UPSQL實時同步

對Moray來說，同步UPSQL資料就是通過binlog dump的協議，把自己偽裝成一個從庫，獲取日誌來進行解析處理。Moray設計的內部協議格式保證了資料庫回放的資料的事務特性，同時為了配合UPDRDB，也支援XA協議以完成分散式事務的同步。

接下來看看高可用問題，在資料同步的時候一般考慮到高可用主要有兩點：Moray本身的高可用和資料庫裡主從的高可用切換。現在的策略是每組一個資料分片（一組主備庫）去共享一條同步鏈路。

這樣，Moray與UPSQL-Proxy（或者DRDB）互動，依靠UPSQL-Proxy保證主從庫可以在異常時如預期切換，主庫上未同步的資料日誌在從庫上也能獲取，不會有資料丟失的問題。

那麼Moray自身的高可用是怎麼去做到的呢？分為兩種情況，如果沒有任何其它底座的話，Moray自身只能做冷備，當Moray程式當機或者是無法恢復的時候，需要去手動切換到冷備程式。

這並不難，因為Moray的啟動配置本身並不複雜，配置以及同步進度資訊支援寫入資料庫或者Zookpeer，完全可以實現探測指令碼獲取啟動資訊，重新拉起程式；銀聯在使用Moray的時候，會將其和自研的資料庫平臺（DBAASE）整合，如果Moray當機DBAASE可以及時感知，由它來重新建立同步鏈路。

再來看擴容問題，UPDRDB支援資料庫的線上擴容，與之對應的，Moray的擴容策略目前是由源端的資料分片來決定的，因為獲取binlog只能從每一組資料庫裡面去獲取。這樣的話意味著源端有多少個資料庫分片的組，就有多少個Moray的同步線路。

DDL變更其實對很多資料同步工具來說是一個比較頭疼的問題。之前的版本暫時不支援DDL語句同步，在某些情況下，雙活資料同步時，需要暫停Moray程式。最新的Moray版本中，DDL語句同步時，將會把每一個資料表的版本都儲存起來。在內部協議格式增加版本號，根據版本號來決策當前使用哪一個版本的資料表結構。

為了滿足多變的業務場景，Moray支援使用lua指令碼配置資料形變。Moray是用C語言寫的，C語言能夠很方便的去呼叫lua指令碼。如果需要做比較靈活的形變，那隻需要提供一個lua函式。Lua本身是很靈活的語言，使用者可以去對資料做任意的形變。

Moray-Upsql在實現各類同步需求時，效能也足以支援銀聯所有的業務壓力，以內部通用的轉接測試為例，目前DRDB叢集效能在二十萬TPS以上，使用Moray完全沒有問題。

2.4 UPRedis實時同步

再簡單說一下Moray-Redis。與UPSQL有所區別的地方在於前端模組解析EOF日誌，後端使用了PIPELINE設計去寫目的端的快取，當然異地傳輸時需要對報文進行壓縮。實際的傳輸效能在10萬QPS左右。

在做高可用設計時，Moray使用了Redis官方推薦的HA的sentinel元件。正常情況下，Moray連線Redis從庫同步資料。遇到故障時，如果是一主一從，只能從主庫（或切換後的主庫）再去同步資料。因為redis是單執行緒的工作機制，直接去從主庫上同步肯定會影響一些效能。如果是一主多從的話，Moray則從其他的從庫繼續同步資料，Moray通過sentinel資訊來得知主從切換的資訊。

 3  案例實踐

再簡單介紹一下銀聯的一些實踐和Moray研發的近況。Moray是在去年2月份開始投入研發，三個月做了一個版本並release，之後一直在不斷做測試和驗證。

在9月份時第一次業務上線，用於TSP（支付Token標記）的聯機和管理遷移。現在已上線的系統包括TSP、無卡前置的管理系統、雲閃付的統一賬戶平臺、管理全國商戶的平臺系統以及二維碼支付平臺。陸續會有更多的系統投入使用。

4    未來規劃

在未來Moray需要做的事情可能分以下幾個方向。

一是更多的模組和外掛。通過解析Oracle日誌（Logminer效能有限）實現Oracle的資料同步，以及支援寫入Kafka或更多的資料平臺。

二是Moray叢集化，進一步簡化部署配置和集中管理，銀聯也正朝著金融雲平臺的方向探索未來，所以也需要有一個類似DTS的資料傳輸平臺。Moray也會對此作出適配。

期待銀聯能為資料庫做一些更多技術方面的輸出，也希望大家一起努力，把開源或自主的資料庫的技術做得更好，共同向前。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31545814/viewspace-2648318/，如需轉載，請註明出處，否則將追究法律責任。