-
產(chǎn)品
數(shù)據(jù)庫私有云RDS基于Kubernetes技術(shù)，提供企業(yè)級數(shù)據(jù)庫RDS服務(wù)
- 信創(chuàng)生態(tài)
-
解決方案
場景解決方案多業(yè)務(wù)場景覆蓋，企業(yè)放心之選
- 行業(yè)案例
- 資源
- 合作伙伴
-
售后支持
-
關(guān)于我們
了解我們加入我們
兩地三中心和異地多活都是分布式系統(tǒng)的關(guān)鍵技術(shù)，用于保證系統(tǒng)的高可用性和容錯性。其中最關(guān)鍵的技術(shù)無疑是數(shù)據(jù)同步、同步防環(huán)和數(shù)據(jù)沖突解決。
兩地三中心架構(gòu)是一種分布式系統(tǒng)的架構(gòu)模式，用于保證系統(tǒng)的高可用性和容錯性。它將整個系統(tǒng)劃分為三個數(shù)據(jù)中心：兩個位于同城，一個位于異地。其中，同城的兩個數(shù)據(jù)中心分別承擔主備的角色，異地數(shù)據(jù)中心則作為備份。
在兩地三中心架構(gòu)中，同城的兩個數(shù)據(jù)中心之間通過高速網(wǎng)絡(luò)進行數(shù)據(jù)同步，實現(xiàn)了主備切換和故障恢復(fù)。當主數(shù)據(jù)中心發(fā)生故障時，備份數(shù)據(jù)中心會自動接管服務(wù)，保證系統(tǒng)的連續(xù)性和可用性。同時，異地數(shù)據(jù)中心作為備份，可以在主備數(shù)據(jù)中心都出現(xiàn)故障時提供服務(wù)。
兩地三中心架構(gòu)具有以下優(yōu)點：
高可用性：通過主備切換和異地備份，保證了系統(tǒng)的高可用性和連續(xù)性。
容錯性：當某個數(shù)據(jù)中心或服務(wù)器出現(xiàn)故障時，可以快速切換到其他可用的數(shù)據(jù)中心或服務(wù)器上，保證了系統(tǒng)的容錯性。
靈活性：可以根據(jù)業(yè)務(wù)需求靈活配置數(shù)據(jù)中心的數(shù)量和位置，滿足不同的業(yè)務(wù)需求。
性能優(yōu)化：可以通過負載均衡等方式優(yōu)化系統(tǒng)的性能，提高用戶體驗。
安全性：可以通過數(shù)據(jù)同步和容災(zāi)備份等方式保證數(shù)據(jù)的安全性和完整性。
以MySQL數(shù)據(jù)庫為例，可以通過同城雙向復(fù)制和異地異步復(fù)制來實現(xiàn)兩地三中心架構(gòu)。
以下是兩地三中心架構(gòu)的部署架構(gòu)：
主數(shù)據(jù)中心：包括一個MySQL主庫和一個或多個MySQL從庫，主庫用于寫入操作，從庫用于讀取操作。
同城備份數(shù)據(jù)中心1：包括一個MySQL主庫和一個或多個MySQL從庫，主庫用于備份主數(shù)據(jù)中心的數(shù)據(jù)，從庫用于讀取操作。
異地備份數(shù)據(jù)中心2：包括一個MySQL主庫和一個或多個MySQL從庫，主庫用于備份主數(shù)據(jù)中心的數(shù)據(jù)，從庫用于讀取操作。
盡管兩地三中心架構(gòu)具有很多優(yōu)點，但也存在一些缺陷：
成本高：由于需要建設(shè)多個數(shù)據(jù)中心和進行數(shù)據(jù)同步等操作，所以成本較高。
配置復(fù)雜：兩地三中心架構(gòu)需要對系統(tǒng)進行詳細的規(guī)劃和配置，包括主備切換、數(shù)據(jù)同步、負載均衡等方面，因此配置比較復(fù)雜。
配置這么復(fù)雜，而且同城備份中心和異地備份中心基本上都用不到，造成了大量的資源浪費；并且大部分用戶并不能做到每個月/季度做一次容災(zāi)演練，導(dǎo)致真正發(fā)生機房異常的情況下，同城或者異地容災(zāi)中心并不能派上用場，用戶做兩地三中心并沒有什么動力。
一般企業(yè)的選擇是：對部分核心業(yè)務(wù)和有監(jiān)管要求的數(shù)據(jù)庫才會搭建同城容災(zāi)，并且對異地容災(zāi)會盡量縮減規(guī)模，例如：主中心是一主兩從，而異地容災(zāi)中心可能只有一個數(shù)據(jù)庫實例，去掉了從機。
總之，兩地三中心架構(gòu)的部署需要對系統(tǒng)進行詳細的規(guī)劃和配置，并且需要考慮多個數(shù)據(jù)中心之間的協(xié)調(diào)和管理。
上面說的兩地三中心和異地容災(zāi)方案成本高、配置復(fù)雜、真正需要的時候不一定用的上，有些企業(yè)特別是業(yè)務(wù)在全國甚至全球范圍需要本地化訪問時會采用異地多活(或者稱為單元化)的解決方案。
異地多活架構(gòu)（Active-Active Architecture）是一種分布式系統(tǒng)架構(gòu)，它允許多個數(shù)據(jù)中心同時處理用戶請求，并且這些數(shù)據(jù)中心之間可以相互協(xié)作，實現(xiàn)數(shù)據(jù)的共享和同步。異地多活架構(gòu)有以下優(yōu)缺點：
優(yōu)點：
高可用性：異地多活架構(gòu)可以在多個數(shù)據(jù)中心之間進行負載均衡和故障轉(zhuǎn)移，從而提高了系統(tǒng)的可用性和容錯性。
低延遲：由于數(shù)據(jù)中心之間可以相互協(xié)作，因此可以將數(shù)據(jù)盡可能地靠近用戶，減少網(wǎng)絡(luò)延遲和響應(yīng)時間。
數(shù)據(jù)共享：異地多活架構(gòu)可以實現(xiàn)數(shù)據(jù)的共享和同步，從而提高了數(shù)據(jù)的可靠性和一致性。
靈活性：異地多活架構(gòu)可以根據(jù)實際需求進行擴展和縮減，從而滿足不同規(guī)模和復(fù)雜度的業(yè)務(wù)需求。
異地多活最大的挑戰(zhàn)來自于數(shù)據(jù)庫，最主要的來自于數(shù)據(jù)一致性：由于異地多活架構(gòu)需要實現(xiàn)數(shù)據(jù)的共享和同步，因此需要解決數(shù)據(jù)一致性的問題，避免出現(xiàn)數(shù)據(jù)沖突和錯誤。
閑話少說，舉例為證：假設(shè)你是一個MySQL DBA，你們公司有三個機房：北京、廣州和上海。領(lǐng)導(dǎo)要求你提供一個解決方案：讓每個地區(qū)的客戶都就近訪問本地的數(shù)據(jù)庫，華北的客戶數(shù)據(jù)存儲在北京的數(shù)據(jù)庫，華東的客戶數(shù)據(jù)存儲在上海的數(shù)據(jù)庫，華南的客戶數(shù)據(jù)存儲在廣州的數(shù)據(jù)庫上。這些數(shù)據(jù)庫的數(shù)據(jù)需要能相互同步，保證數(shù)據(jù)一致，以便華北的用戶出差到上海以后可以就近訪問上海數(shù)據(jù)庫上的數(shù)據(jù)（這些數(shù)據(jù)是華北這個客戶的數(shù)據(jù)從北京同步到上海的），在上海出差產(chǎn)生的數(shù)據(jù)同樣應(yīng)該同步回北京。這樣客戶出差回北京以后，他可以繼續(xù)訪問和更新“最新”的數(shù)據(jù)。
對應(yīng)的，你就需要搭建一個異地多活架構(gòu)來實現(xiàn)數(shù)據(jù)的就近訪問和不同中心的數(shù)據(jù)同步。具體的方案如下：
在每個機房都部署一套MySQL數(shù)據(jù)庫。
通過VPN隧道或者其他技術(shù)，打通各個機房的網(wǎng)絡(luò)，讓MySQL可以建立復(fù)制鏈路。
配置MySQL GTID復(fù)制，搭建雙向復(fù)制，將不同機房之間的數(shù)據(jù)進行雙向同步，保證數(shù)據(jù)的一致性和可靠性。
簡單的示意圖如下：
總之，異地多活架構(gòu)是一種高級別的分布式系統(tǒng)架構(gòu)，具有高可用性、低延遲、數(shù)據(jù)共享和靈活性等優(yōu)點，但也存在復(fù)雜性、成本較高、數(shù)據(jù)一致性和安全性等缺點，需要根據(jù)實際情況進行選擇和應(yīng)用。
如前所述，不管是兩地三中心還是異地多活，其中比較關(guān)鍵的就是雙向同步（兩地三中心中的同城雙向同步，異地多活的多中心雙向同步），保證業(yè)務(wù)在一個中心寫的數(shù)據(jù)可以復(fù)制到另外一個中心。數(shù)據(jù)庫原生提供的復(fù)制有些本身是可以搭建雙向復(fù)制的，但是這種方式只能做到實例級別同步（無法支持where條件過濾或者做對象名映射）、無法定制化修改（需要有內(nèi)核修改能力并且修改后必須停業(yè)務(wù)以升級數(shù)據(jù)庫），監(jiān)控和管理不直觀（命令行式，操作不便）。一般使用專業(yè)的雙向同步工具或者其他第三方工具來實現(xiàn)，以保證易用性、易維護性，提供定制化修改和監(jiān)控管理功能。
沃趣科技的DBMotion實現(xiàn)了MySQL和openGauss的雙向同步，它不依賴于數(shù)據(jù)庫原生的復(fù)制，采用獨立的cdc解析模塊從源庫中獲取重做日志并解析，通過sink模塊將源庫中的變更并行應(yīng)用到目標庫。如下圖所示，如果不做特殊處理，將會出現(xiàn)循環(huán)復(fù)制的問題。
還是以MySQL為例，上圖中兩個MySQL實例分別位于華東中心和華南中心，如果通過DBMotion做雙向同步，那么在華東中心插入一行數(shù)據(jù)，通過DBMotion在華南回放，也會插入一行數(shù)據(jù)；但是反向的DBMotion解析到這條insert的數(shù)據(jù)，又會將它同步回華東中心。也就產(chǎn)生了循環(huán)復(fù)制，如果是無主鍵表，insert不產(chǎn)生唯一約束沖突，這個insert將在華東和華南永續(xù)循環(huán)復(fù)制下去。
當然，通過MySQL基于server-id是可以避免的。如圖，在db1插入的數(shù)據(jù)，插入到db2的時候，在日志中也記錄為server-id=1。這樣dbmotion的反向復(fù)制，檢查到server-id為1的日志要同步回來，就可以安全的過濾掉。
但是這種方式需要精準的控制每個中心所有數(shù)據(jù)庫的server-id，下圖中如果是server-id=1產(chǎn)生的更新，就會在華南中心的雙master實例間做無限循環(huán)復(fù)制。
當然，MySQL也可以利用GTID來實現(xiàn)，但是GTID并不是所有的客戶都開啟的，如何兼容是一個問題。
上面只是以MySQL這種邏輯復(fù)制避免循環(huán)復(fù)制的方案。openGauss原生的復(fù)制目前是另外一種方案：華東中心復(fù)制寫入華南中心的時候不記錄日志。這樣反向復(fù)制同步時，取不到正向同步的數(shù)據(jù)，也就不會形成循環(huán)復(fù)制。當然這種方式會導(dǎo)致華南中心的備庫沒有華東中心過來的數(shù)據(jù)，對于多中心數(shù)據(jù)同步也是無法級聯(lián)同步數(shù)據(jù)的。
DBMotion采用的是類似于server-id打標的方式，在數(shù)據(jù)寫入華南中心的時候?qū)θ罩具M行標記， 保證DBMotion寫入的數(shù)據(jù)，在DBMotion日志解析的時候能夠被認出來，避免數(shù)據(jù)被復(fù)制回華東中心。
如果擴展到多中心，還是會存在循環(huán)復(fù)制的問題，如圖：在華北中心插入的數(shù)據(jù)被標識為region3，復(fù)制到華東和華南中心時，他們發(fā)現(xiàn)數(shù)據(jù)都不是自己發(fā)出的時候，就會出現(xiàn)循環(huán)復(fù)制的問題。
此時，DBMotion就需要做額外的處理，在華東中心把華北過來的數(shù)據(jù)和業(yè)務(wù)請求的數(shù)據(jù)統(tǒng)一標記成region1，這樣在華南過來的業(yè)務(wù)數(shù)據(jù)沒有標記，而從華東過去的數(shù)據(jù)都有標記，就可以將打標的更新成功過濾。
當然，這種同步還是避免不了用戶故意搭建的環(huán)形復(fù)制鏈路產(chǎn)生循環(huán)復(fù)制，所以DBMotion支持的異地多活，目前只能支持樹形復(fù)制，類似于下圖的結(jié)構(gòu)。在region-id=6的數(shù)據(jù)庫上插入一筆數(shù)據(jù)，通過DBMotion同步到region-id=2的節(jié)點時，會將2標記為同步到region-id為1和5的節(jié)點，并且從1和5同步回來時會自動被過濾掉，之后會依次被同步到3,4;7;8。
綜上，“同步防環(huán)”可以解決一條更新在多個中心上循環(huán)復(fù)制的問題，異地雙活的關(guān)鍵技術(shù)難點“循環(huán)復(fù)制”，可以通過打標忽略的方式解決。
異地多活又稱為單元化，前提是業(yè)務(wù)可以單元化，讓客戶同時只在一個單元上操作。
如前文中提到的，北京的用戶無論是在北京還是在上海，只會在不同的時間點更新自己的數(shù)據(jù)，不會出現(xiàn)在多個中心同時更新同一筆數(shù)據(jù)的情況。如果需要在同時在同一個時間點更新同一個數(shù)據(jù)，如北京和上海的用戶同時匯款給廣州的客戶，就可能同時對廣州的客戶賬戶有兩個增加余額的操作。
這種同時在多中心操作同一筆數(shù)據(jù)的方式，需要在業(yè)務(wù)上嚴格避免，或在業(yè)務(wù)架構(gòu)上使用集中式架構(gòu)，在同一個中心(或者通過同城多中心的分布式數(shù)據(jù)庫)應(yīng)對所有單元的更新請求；或?qū)I(yè)務(wù)進行單元化分拆（以上面的匯款案例為例，廣州的用戶應(yīng)該在北京和上海都有子賬戶，收到匯款只是在北京和上海的子賬戶上增加余額，對應(yīng)的廣州的這個用戶查詢余額就需要匯總所有中心的賬戶余額了）。
另外，復(fù)制延遲也有可能導(dǎo)致沖突，例如北京的客戶出差到了上海來更新自己的數(shù)據(jù)，此時在北京的部分更新還沒有同步到上海，那么也會出現(xiàn)類似于兩邊同時寫同一份數(shù)據(jù)的沖突。
上述數(shù)據(jù)沖突的問題，都必須在業(yè)務(wù)或者說在數(shù)據(jù)庫的上層解決。通過數(shù)據(jù)同步將數(shù)據(jù)已經(jīng)寫入到數(shù)據(jù)庫后，數(shù)據(jù)沖突在“下層”是無法解決的，只能檢測沖突，提醒客戶有沖突發(fā)生，并提供相關(guān)的沖突解決策略去輔助客戶解決這個問題。
DBMotion通過匹配前鏡像和后鏡像更新報錯來發(fā)現(xiàn)沖突，目前提供兩種機制來處理沖突：
復(fù)制鏈路可以指定沖突錯誤忽略列表，用戶可以指定對部分沖突報錯直接忽略報錯，類似于MySQL的replica_skip_errors錯誤。例如：用戶需要對Duplicate Key報錯進行忽略，可以直接在沖突錯誤忽略列表中增加1062錯誤。
復(fù)制檢測到?jīng)_突可以按照復(fù)制沖突策略來自動處理沖突。
DBMotion復(fù)制檢測到?jīng)_突目前有三種沖突解決策略可以指定：
報錯：DBMotion在檢測到?jīng)_突以后就報錯停止，配合上短信和郵件報警，用戶收到報錯后可以查看并手工解決沖突以后，點“繼續(xù)”會讓DBMotion斷點續(xù)傳從上次報錯的位置繼續(xù)同步。
忽略：DBMotion在檢測到?jīng)_突后，只會在日志中記錄沖突，忽略錯誤并繼續(xù)同步。
覆蓋：DBMotion會直接以主鍵或者唯一鍵對目標庫進行覆蓋，保證目標庫和源庫一致，繼續(xù)同步。
總結(jié)
綜上，沖突解決是異地多活和分布式數(shù)據(jù)庫面臨的通用問題，需要在業(yè)務(wù)架構(gòu)上盡量避免。DBMotion在數(shù)據(jù)庫同步的時候提供了兩種機制，三種策略來輔助客戶檢測沖突和設(shè)置沖突解決策略。
目前DBMotion已經(jīng)在Squids上上線，為客戶提供異地、跨云的MySQL和openGauss多活業(yè)務(wù)訪問，未來將繼續(xù)支持更多的多活場景。
服務(wù)電話： 400-678-1800 （周??周五 09:00-18:00）
商務(wù)合作： 0571-87770835
市場反饋： marketing@woqutech.com
地址： 杭州市濱江區(qū)濱安路1190號智匯中?A座1101室
0571-87770835