本發(fā)明涉及計算機(jī)網(wǎng)絡(luò)領(lǐng)域，具體涉及一種數(shù)據(jù)同步方法和裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)使用的普及，以及互聯(lián)網(wǎng)應(yīng)用7*24全天服務(wù)的天然屬性，網(wǎng)站的可用性對大型互聯(lián)網(wǎng)公司越來越重要。即使幾分鐘的宕機(jī)都有可能給互聯(lián)網(wǎng)公司和用戶造成巨大損失。導(dǎo)致網(wǎng)站宕機(jī)的因素主要包括服務(wù)器、網(wǎng)絡(luò)設(shè)備、機(jī)房、isp網(wǎng)絡(luò)線路、天氣自然災(zāi)害等不可抗力。冗余是提升網(wǎng)站可用性的主要方式。通常大型互聯(lián)網(wǎng)公司都會將重要的網(wǎng)站系統(tǒng)部署到多臺服務(wù)器、多個機(jī)房、多個城市、甚至全球。對于數(shù)據(jù)系統(tǒng)來說，在比較穩(wěn)定可靠的網(wǎng)絡(luò)環(huán)境下，我們一般使用數(shù)據(jù)庫本身提供的復(fù)制技術(shù)來實(shí)現(xiàn)數(shù)據(jù)冗余。當(dāng)網(wǎng)絡(luò)環(huán)境變得不穩(wěn)定時，數(shù)據(jù)庫自身提供的復(fù)制技術(shù)往往達(dá)不到足夠的健壯性；而且無法提供足夠低的復(fù)制延時。因此，在跨機(jī)房、跨地域的網(wǎng)絡(luò)環(huán)境中，如何提供一種低延時高可用的數(shù)據(jù)庫同步系統(tǒng)，就成為提高可用性的關(guān)鍵。

現(xiàn)有技術(shù)之一是mysqlreplication，即mysql主從復(fù)制。mysql復(fù)制是一種基于事務(wù)日志傳輸(logshipping)的主從同步技術(shù)。當(dāng)主服務(wù)器上有事務(wù)寫入時，主服務(wù)器先將事務(wù)數(shù)據(jù)寫入事務(wù)日志(writeaheadlog)中，然后再執(zhí)行事務(wù)包含的數(shù)據(jù)變更，修改數(shù)據(jù)文件。在從服務(wù)器上執(zhí)行指定主服務(wù)器的操作后，從服務(wù)器運(yùn)行io線程，連接主服務(wù)器，向主服務(wù)器請求事務(wù)日志傳輸。從服務(wù)器上的io線程將接收到的事務(wù)日志寫入本地的事務(wù)日志文件(relaylog)。從服務(wù)器同時運(yùn)行sql線程，讀取本地的事務(wù)日志文件，逐條執(zhí)行事務(wù)中包含的數(shù)據(jù)變更，最終寫入從服務(wù)器的數(shù)據(jù)文件。

另一種現(xiàn)有技術(shù)是oraclegoldengate。這是一種支持oracle、mysql等多種數(shù)據(jù)庫的復(fù)制技術(shù)。其原理上與mysql類似，也是基于事務(wù)日志傳輸，主要不同在于oraclegoldengate是以第三方組件的方式運(yùn)行，部署上獨(dú)立于數(shù)據(jù)庫系統(tǒng)。

但是，這兩種技術(shù)都存在較為明顯的缺點(diǎn)。mysql主從復(fù)制技術(shù)在日常數(shù)據(jù)庫運(yùn)維中使用非常廣泛，主要是因為這種復(fù)制技術(shù)由mysql自身直接提供，不需要安裝任何三方組件；另外使用上比較簡單。不過，mysql復(fù)制一直遭到詬病的地方就在于復(fù)制性能。直到mysql5.6，mysql才開始對復(fù)制性能進(jìn)行優(yōu)化。另外，由于mysql復(fù)制由mysql自身提供，外圍系統(tǒng)無法介入，也就無法實(shí)現(xiàn)諸如異構(gòu)復(fù)制、雙向復(fù)制、消息分發(fā)等高級功能。oraclegoldengate由于對oracle的良好支持，在電信、銀行等傳統(tǒng)行業(yè)應(yīng)用比較廣泛。但其商業(yè)產(chǎn)品屬性，決定了有限的擴(kuò)展性，無法適應(yīng)互聯(lián)網(wǎng)公司需求復(fù)雜多變的使用場景。

技術(shù)實(shí)現(xiàn)要素：

有鑒于此，本發(fā)明提供了一種低延時高可用的數(shù)據(jù)同步方法和裝置。其提高mysql復(fù)制的性能，跟mysql復(fù)制相比提高5-10倍。同時，本發(fā)明從設(shè)計上提供了通過事務(wù)日志傳輸進(jìn)行數(shù)據(jù)變更分發(fā)的架構(gòu)靈活性。

根據(jù)本發(fā)明的實(shí)施例的第一方面，提供一種數(shù)據(jù)同步方法，包括：向中繼器(relay)請求事務(wù)日志，如果無法從中繼器接收事務(wù)日志，則向快照服務(wù)器請求事務(wù)日志；從中繼器或快照(snapshot)服務(wù)器接收事務(wù)日志；以及應(yīng)用事務(wù)日志以同步數(shù)據(jù)。

根據(jù)本發(fā)明的實(shí)施例的第二方面，還提供了一種數(shù)據(jù)同步裝置，包括：請求單元，被配置為向中繼器請求事務(wù)日志，如果無法從中繼器接收事務(wù)日志，則向快照服務(wù)器請求事務(wù)日志；接收單元，被配置為從中繼器或快照服務(wù)器接收事務(wù)日志；以及事務(wù)日志應(yīng)用單元，被配置為應(yīng)用事務(wù)日志以同步數(shù)據(jù)；以及應(yīng)用單元，被配置為接收并應(yīng)用所述事務(wù)日志以同步數(shù)據(jù)。

附圖說明

圖1是示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步中心的示意圖。

圖2是示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步方法的流程圖。

圖3是示出根據(jù)本發(fā)明的實(shí)施例的用于快照服務(wù)器的方法的流程圖。

圖4是示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步裝置的框圖。

具體實(shí)施方式

本發(fā)明從基本原理上跟mysql復(fù)制相同，都是通過將主數(shù)據(jù)庫上的事務(wù)日志傳輸?shù)綇臄?shù)據(jù)庫，然后逐條應(yīng)用到從數(shù)據(jù)庫上。本發(fā)明通過高度并行化改進(jìn)了從數(shù)據(jù)庫端入庫算法，從而提高了復(fù)制性能。

圖1示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步中心的示意圖。數(shù)據(jù)同步中心主要由三個組件構(gòu)成：中繼器(relay)，快照(snapshot)，復(fù)制器(replicator)。整個系統(tǒng)的核心工作流程如下：

(1)relay從數(shù)據(jù)源抽取事務(wù)日志，放到環(huán)形緩存(ringbuffer)中，作為內(nèi)存日志隊列；

(2)replicator跟relay建立連接，請求在線變更(onlinetransfer)，即請求一段增量事務(wù)日志；

(3)relay從ringbuffer中取出對應(yīng)的事務(wù)日志塊，發(fā)送給replicator；

(4)replicator接收事務(wù)日志后，跟目標(biāo)數(shù)據(jù)庫建立連接，并應(yīng)用事務(wù)日志；

(5)如果1.3中relay沒有找到對應(yīng)的事務(wù)日志塊，就發(fā)送未找到通知(例如，404)給replicator；

(6)replicator收到未找到通知404后，跟snapshot建立連接，請求快照增量(snapshotdelta)；

(7)snapshot從其存儲器中取出對應(yīng)的快照增量，發(fā)送給replicator；

(8)replicator收到快照增量后，跟目標(biāo)數(shù)據(jù)庫建立連接，并應(yīng)用事務(wù)日志；

(9)在2-8過程中，snapshot作為一個relay的特殊消費(fèi)端，一直在從relay訂閱所有的在線變更，并寫到存儲器中，作為relay數(shù)據(jù)過期時的后備；

以下將描述本發(fā)明的主要組件中繼器(relya)、復(fù)制器(replicator)以及快照(snapshot)。

1、中繼器(relay)

中繼器relay從來源數(shù)據(jù)庫抽取事務(wù)日志，并對replicator提供日志訂閱服務(wù)，角色上相當(dāng)于mysqlslaveiothread。relay在設(shè)計上以單線程方式連接源數(shù)據(jù)庫，使用環(huán)形緩存(ringbuffer)作為事務(wù)日志存儲的數(shù)據(jù)結(jié)構(gòu)，保證了讀取性能；另外對于大寫入量的數(shù)據(jù)庫，relay還可以使用內(nèi)存鏡像文件作為事務(wù)日志存儲，保證可以接收足夠高的寫入量。

relay的工作流程如下：

1.1eventproducer線程向數(shù)據(jù)源建立連接，發(fā)起事務(wù)日志抽取請求，持續(xù)拉取事務(wù)日志；

1.2eventproducer將拉取過來的事務(wù)日志進(jìn)行解析，根據(jù)事先定義的avroschema，序列化成avro格式；

1.3eventproducer將事務(wù)日志的avro格式添加到ringbuffer中；

1.4如果達(dá)到指定的checkpoint時間間隔，eventproducer將當(dāng)前已寫入ringbuffer的最大事務(wù)日志序號寫入checkpoint；

2、復(fù)制器(replicator)

replicator是事務(wù)日志的消費(fèi)端，從relay或snapshot拉取事務(wù)日志，將事務(wù)日志按配置的一致性應(yīng)用到目標(biāo)數(shù)據(jù)庫，角色上相當(dāng)于mysqlslavesqlthread。

replicator可以根據(jù)一致性配置，靈活的選擇庫、表、行等各級并行度的入庫算法；對于大批量的連續(xù)數(shù)據(jù)寫入，使用批量提交。replicator還提供了統(tǒng)一的事務(wù)日志消費(fèi)接口，消除了與數(shù)據(jù)源事務(wù)日志格式的耦合。

replicator的主要工作流程如下：

2.1relaypuller線程跟relay建立連接，訂閱事務(wù)日志，并將收 到的事務(wù)日志寫入ringbuffer中；

2.2dispatcher從ringbuffer中取出批量的事務(wù)日志塊，根據(jù)一致性配置，對事務(wù)日志進(jìn)行分組、合并、生成入庫語句等處理，發(fā)送到callback線程；

2.3callback線程池，根據(jù)一致性配置，對分組的入庫語句，執(zhí)行并行提交；

2.4當(dāng)2.2.2.1中relaypuller線程從relay收到404時，轉(zhuǎn)而發(fā)起snapshotpuller線程向snapshot發(fā)送訂閱請求，從snapshot收到事務(wù)日志后，繼續(xù)執(zhí)行剩余處理步驟；

2.5每個callback線程執(zhí)行成功后，將已提交成功的事務(wù)序列號寫入線程對應(yīng)的checkpoint；

3、快照(snapshot)

快照(snapshot)負(fù)責(zé)從relay訂閱所有事務(wù)日志，寫入持久存儲作為快照，同時向replicator提供批量日志訂閱服務(wù)，角色上相當(dāng)于mysqlslaverelaylog。

如前所述，正常情況下，replicator直接連接relay，消費(fèi)relay內(nèi)存隊列中的事務(wù)日志。但有些情況下，因為網(wǎng)絡(luò)抖動、目標(biāo)庫的負(fù)載過高等因素，可能導(dǎo)致replicator相對relay落后很多。另外，當(dāng)新的消費(fèi)端加入同一數(shù)據(jù)源的訂閱者時，新消費(fèi)端有冷啟動的問題。為了避免重新從數(shù)據(jù)源做全量快照，snapshot作為relay的一個特殊消費(fèi)端，通過一種高吞吐的消費(fèi)方式，從relay源源不斷的消費(fèi)在線事務(wù)日志，通過對事務(wù)日志的有效處理，最終保存了數(shù)據(jù)源的一份一致快照，即包括了數(shù)據(jù)源庫表中每一行的最新狀態(tài)的快照，同時保留了一段回溯時間比relaybuffer更長的事務(wù)日志。

snapshot主要包括snapshot增量流程和snapshot快照工作流程。

snapshot增量工作流程如下：

3.1當(dāng)replicator向snapshot發(fā)送訂閱請求時，snapshot檢查請求參數(shù)中的起始事務(wù)日志序號，如果起始事務(wù)日志序號在snapshot當(dāng)前的事務(wù)日志存儲(logstore)范圍內(nèi)，則啟動快照增量流程；

3.2snapshotserver從事務(wù)日志存儲中讀取一個事務(wù)日志塊，發(fā)送 給replicator；

3.3重復(fù)執(zhí)行3.2，直到消費(fèi)完事務(wù)日志存儲中的所有日志；

3.4這時，replicator已經(jīng)追趕上relay，于是replicator重新連接relay，繼續(xù)消費(fèi)在線變更；

snapshot快照工作流程如下：

3.1當(dāng)replicator向snapshot發(fā)送訂閱請求時，snapshot檢查請求參數(shù)中的起始事務(wù)日志序號，如果起始事務(wù)日志序號不在snapshot當(dāng)前的事務(wù)日志存儲范圍內(nèi)，則啟動快照傳輸流程；

3.2snapshotserver從快照存儲中讀取一個事務(wù)日志塊，發(fā)送給replicator；

3.3重復(fù)執(zhí)行3.2，直到消費(fèi)完快照存儲中的所有日志；

3.4replicator繼續(xù)請求snapshot，進(jìn)入快照增量工作流程。

此外，本發(fā)明還提供了高可用設(shè)計，包括：

4.1檢查點(diǎn)(checkpoint)機(jī)制為整個系統(tǒng)中提供了事務(wù)日志的安全生產(chǎn)和消費(fèi)的保障。為了保證checkpoint的跨機(jī)器、跨機(jī)房的高可用性，我們選擇zookeeper作為checkpoint存儲機(jī)制。zookeeper使用跨機(jī)房部署機(jī)構(gòu)，保證checkpoint跨機(jī)房可用。

4.2relay作為高性能的事務(wù)日志的中轉(zhuǎn)地，對于保證整個系統(tǒng)端到端的低延時非常重要。為了保證relay的高可用性，我們選擇zookeeper實(shí)現(xiàn)relay的active-standbyfailover機(jī)制。

另外，本發(fā)明還提供一個通用的api接口，方便三方系統(tǒng)訂閱主數(shù)據(jù)庫上的數(shù)據(jù)變更。

圖2是示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步方法200的流程圖。所述方法200可以在replicator中執(zhí)行。

在步驟201中，向中繼器請求事務(wù)日志。步驟202，判斷中繼器是否存在所請求的事務(wù)日志。如果中繼器中存在所請求的事務(wù)日志，則在步驟204，從中繼器接收事務(wù)日志。如果中繼器中不存在所請求的事務(wù)日志，在步驟203向快照服務(wù)器請求事務(wù)日志，然后在步驟204從快照服務(wù)器接收事務(wù)日志。在步驟205，應(yīng)用事務(wù)日志以同步數(shù)據(jù)。

圖3是示出根據(jù)本發(fā)明的實(shí)施例的用于快照服務(wù)器的方法300的 流程圖。

在步驟301，快照服務(wù)器從replicator接收事務(wù)日志請求。在步驟302，判斷事務(wù)日志存儲中是否存在所請求的事務(wù)日志。如果事務(wù)日志存儲中存在所請求的事務(wù)日志，則在步驟303向replicator發(fā)送該事務(wù)日志。如果在事務(wù)日志存儲中不存在所請求的事務(wù)日志，則在步驟304中，從快照存儲中獲取事務(wù)日志，并向replicator發(fā)送該事務(wù)日志。

圖4是示出根據(jù)本發(fā)明的實(shí)施例的數(shù)據(jù)同步系統(tǒng)400的框圖。所述數(shù)據(jù)同步裝置400包括：請求單元401，被配置為向中繼器請求事務(wù)日志，如果無法從中繼器接收事務(wù)日志，則向快照服務(wù)器請求事務(wù)日志；接收單元402，被配置為從中繼器或快照服務(wù)器接收事務(wù)日志；以及應(yīng)用單元403，被配置為應(yīng)用事務(wù)日志以同步數(shù)據(jù)。

綜上，本發(fā)明通過一種分布式內(nèi)存隊列的數(shù)據(jù)結(jié)構(gòu)和消費(fèi)端并行入庫的優(yōu)化算法，可以提供跨機(jī)房、跨地域場景下低延時、高可用的數(shù)據(jù)庫同步機(jī)制。