爲何主動跨數據複製在5G時代很是重要？

01 概述

5G和IoT等新技術的融合給電信行業帶來了快速而巨大的變革。這些新技術正在推進數據量、速度和多樣性的空前增加。數據的增加致使傳統系統發生故障，因此電信公司不得不面臨一個艱難的選擇：繼續嘗試「傳統系統與現有系統一塊兒使用」，抑或尋找新的事物，而且越快越好，由於世界上沒有哪家電信公司的數據會變得愈來愈慢，與此同時，***數量變得愈來愈多且更具侵略性。

爲了更及時地提供最新數據，跨數據中心複製（XDCR）應運而生。這種技術已經存在了數十年，但使用傳統技術來運做變得昂貴，且使用5G技術來運做也很困難，沒法正確執行。傳統RDBMS上的主動XDCR變得很複雜且容易出錯。企業也很快意識到，他們要麼徹底替換其數據庫，要麼將冒着在永久性技術和經濟上處於不利地位的風險。

在本文中，咱們將討論XDCR是什麼，以及爲何須要XDCR；什麼是主動-主動XDCR，爲何這麼多公司面臨這種挑戰？最後，VoltDB如何以一種主動-主動XDCR的方式避免衝突，還能夠對複雜的流數據進行全面的容錯，並進行10毫秒如下的智能決策，而同時不會損害數據準確性。

首先，讓咱們定義咱們的術語。

02 什麼是XDCR？

在最基本的級別上，XDCR僅意味着更改會朝多個方向進行，即，一次在多個地理位置上擁有多個實時數據庫集羣，以便在更新本地數據庫時，更改會自動傳播到全部其餘副本。
您要這樣作的主要緣由有兩個：

1.業務連續性：中斷是不可避免的，但不該決定您的命運

不一樣位置具備多個數據庫實時副本的最初動機是，若是地震、火災或其餘事件致使原始副本沒法運行，企業能夠繼續運行。

早期的實現具備數據庫的一個主副本和一個或多個遠程只讀副本，這些副本可能已經徹底更新，也可能還沒有徹底更新。將此副本設爲「實時」是一個手動過程，很容易須要30分鐘。從業務角度來看，這帶來了明顯的問題。首先，數據丟失的數量可能很大。其次，主管人員對於任何須要複雜的，通過精心排序的手動事件鏈才能工做的系統，可能會感到不安。當切換隻會在最大混亂的時刻發生時，他們會特別緊張。

最終，XDCR涉及到兩個相互鏈接的可互換數據庫，從而避免了整個切換過程。這就是所謂的「主動-主動」架構（更多內容請參見下文）。可是提供數據庫行業所謂的「主動-主動解決方案」要比看起來困可貴多。

在實踐中，使用傳統技術進行跨數據中心複製已經有十多年的歷史了，可是它很容易將項目成本增長了十倍，同時又帶來了足夠的運營挑戰和「陷阱」，從而使淨可靠性成爲現實。沒有比單個系統更好的了。

2. 5G和延遲：您的數據須要在您的客戶所在的地方

若是您是對延遲要求極其嚴苛的應用程序的企業，則數據中心與終端用戶之間的距離將會變得很重要。

數據以約124英里/毫秒的速度經過光纜進行傳輸。所以，若是您的數據中心位於紐約，而您的客戶位於2,900英里以外的舊金山，則任何消息往返至少須花費23毫秒至46毫秒。
若是您決定是否必須在20毫秒內接通電話，而決策過程自己又須要10毫秒，那麼數據中心的距離不能超過5毫秒（約600英里）。

這意味着您將須要備份多個實時的運營數據副本，以便在不一樣的地理位置運營您的業務。實際上，您可能須要兩個以上。

03 什麼是主動-主動XDCR？

關於什麼是XDCR以及「主動－主動」的含義是什麼有不少困惑。現在，許多數據庫架構師和管理員可能會交換使用這些術語。這是不太確切的——主動—主動和XDCR並不相同，由於「主動-主動」是一種進行XDCR的方式。可是，它的確指出了主動-主動架構的廣泛性和亟需性。

所以，首先，咱們將定義「主動-主動」，並將其與「主動-被動」區分開。
主動-被動意味着有多個數據庫副本，可是隻有一個是可更改的（即，主動的），而其餘副本則被告知更改。這看起來很簡單，可是將備份數據庫設置爲「主動」（因原始的「主動」數據庫已失敗，一般須要人工干預），它卻沒法分辨出將「主動」數據庫刻錄到地面的數據中心與拔下網絡電纜的人的區別。而咱們的目標是下降系統範圍的延遲，這對咱們的目標毫無幫助。

Active-active意味着您有兩個數據庫，這兩個數據庫均可以實時更新，而且兩個數據庫均可以相互溝通同步更新。這避免了上面咱們討論過的「什麼時候成爲主動」的問題決策，而且如今咱們能夠解決衝突（更多內容請參見下文）。

主動-主動-主動，這意味着將另外一個集羣添加到您的部署中。而這種配置比您想象的更常見。若是客戶對地理冗餘有嚴格的要求（跨越多個地理位置的數據中心的物理隔離）而且還必須進行主體OS /硬件升級，那麼最簡單的方法一般是使用新的設備——在棄用較舊的羣集之一以前，能夠對其進行測試的配置。這樣作的成果是，咱們的大多數「主動-主動-主動」集羣將在某個時候變成「主動-主動-主動-主動」。

04 爲何主動-主動XDCR如此困難？

藉助足夠的「血液和財富」（即以開發人員時間的形式和附加的第三方軟件），咱們幾乎能夠建立任何數據庫來支持某種形式的主動-主動XDCR。這就是爲何如此衆多的供應商聲稱他們能夠這樣作。所以，問題不是「‘某產品’是否符合支持主動-主動的法律要求？」而是「我可否負擔得起以主動-主動模式部署X產品相關的人力、技術和財務成本？」。

許多企業在未首先了解如何在不增長運營成本的狀況下實現主動-主動XDCR，或試圖主動-主動XDCR，最終要麼放棄，要麼爲妥協的解決方案而苦惱。

主動-主動XDCR的核心問題是衝突的處理。

爲了說明衝突可能形成的麻煩，咱們假設咱們正在談論預付費移動電話信用，而且在三個位置（位置A，位置B和位置C）中複製了相同的數據庫，每一個位置相距數百英里。咱們假設系統跟蹤大約5000萬終端用戶，每一個終端用戶擁有50-100條各類記錄。

在這種狀況下，避免衝突幾乎是不可能的。最明顯的衝突類型是，用戶在位置A上鍊接到數據庫並花費其最後的信用額度，而後以某種方式鏈接到位置B並再次花費相同的額度，而後此活動的消息到達位置A。

這聽起來彷佛不太可能，可是在多個用戶共享預付費呼叫方案時經常會發生。若是用戶位於流量在位置A和位置B之間不斷切換的邊界時，也會發生這種狀況。
可是，更大的問題不是您有一個單一的衝突，您能夠花點時間修復全部問題，而後中止全部衝突。您可能擁有的不止一個衝突，而當您發現這一點時，錯誤決策的二階和三階後果已經在您的整個企業中蔓延開來。

爲何咱們不能在兩站點之間僅使用「兩階段提交」？
「兩階段提交」是一種過去經常使用於協調多個站點之間的更改的技術。對於每筆交易，其形式爲站點之間的漫長對話，並最終雙方承認數據項已更改。雖然它能夠完成其核心任務，但因爲如下緣由，對於主動-主動XDCR來講並不實用：
它沒法縮放。咱們須要每秒可以完成數千筆交易，而兩階段提交根本沒法擴展到該級別。
它假設全部事情一直在起做用。在兩階段提交體系裏，咱們假設全部站點始終處於打開狀態而且彼此可見。這意味着在站點中斷或網絡問題的狀況下，整個系統都將中止。

05 如何使主動-主動XDCR更加輕鬆

處理衝突的難易程度取決於您使用的數據庫，可是企業能夠作不少事情來避免衝突。
鑑於咱們沒法「設計出」衝突，所以咱們須要考慮減小衝突發生的頻率，並在發生衝突時有效地進行處理。

您能夠按照如下方法進行操做：

1.使用快速傳播

您在站點之間傳播與更新的速度有多快，與您將遇到多少衝突之間，存在反比關係。若是花費5秒鐘而不是500毫秒，那麼發生衝突的窗口將增長10倍，而且您的衝突計數也會相應增長。

XDCR的傳統實現一般創建在最初設計用於填充數據倉庫的更改數據捕獲 （CDC） 應用程序之上。所以，它們多是基於批處理的，可是速度會很慢。它們在設計時還考慮了單向複製，這在嘗試雙向或多方向時會致使問題。

2.最小化配置和自動化

傳統數據中心複製產品的其餘負面後果一般是數據庫與 CDC 產品的差強結合。其一是基礎配置的複雜性：數據庫對象及其複製方式在 DDL 級別徹底脫鉤，這具備顯著的複雜性。

且在出現問題時，也廣泛缺少自動恢復功能。即便在理想條件下，不管使用什麼技術，XDCR都對人們的操做構成挑戰。客戶在XDCR上的操做經驗向咱們代表，即便自動化程度高且配置簡單，最可能形成停機的緣由仍是人爲錯誤。

3.程序衝突地址

鑑於衝突是不可避免的，咱們須要解決它們在現實系統中形成的後果。這必須以自動化的方式完成，由於儘管每小時平均衝突數量不多，但網絡中斷可能致使大量衝突，從而壓倒人類決策者。

這意味着對衝突消息採用標準格式，適用於自動分析和處理。這只是第一步，由於衝突將在部署中的每一個站點的不一樣時間發生。咱們還須要一種存儲衝突的機制。

4.迅速解決衝突，避免形成負面影響

儘管大多數產品使用「最後寫贏」的某種形式來決定數據的最終外觀，但咱們仍然必須處理衝突發生後但在乎識到以前作出的決策的下游後果。實際上，這意味着若是沒有解決衝突的程序機制，在終端用戶注意到這些不可避免的問題以前，您將沒法解決不可避免的問題。若是你迅速解決衝突，你將可以儘可能減小不許確決策的二階和三階效應，不然會致使混亂。

5.嚴苛適應

一旦咱們認可衝突是不可避免的，咱們須要自動解決衝突，另外一個要求忽然變得顯而易見：咱們觀察和試圖解決的任何衝突都必須是完整和完全的。找出大約一半的衝突是沒有用的，由於咱們將沒法解決衝突形成的任何潛在的業務問題。
所以，咱們須要一個符合嚴苛要求的機制來報告衝突，您能夠可靠地假設，一旦您被告知衝突，您就知道這一切，而不只僅是其中的一部分 。

6.支持自動恢復

任何花時間處理分佈在局域網或地理上的數據庫的人都會告訴您，當您正在說話的節點消亡時切換到可行的替換節點可能會有問題，但真正的挑戰是讓節點從新加入羣集或在組件負載不足時向集羣添加新的節點，而不會致使"失效"或徹底中斷。

對於許多較老的產品，從新加入過程的外觀、感受和行爲都像過後諸葛亮。可是，若是節點在無計劃停機和隨之而來的劇情下沒法從新加入，那麼您將發現本身身處一個僅需保持系統正常運行就會耗費數十甚至數百小時的世界。

06 VOLTDB如何進行主動-主動XDCR

除了針對大量事務性工做負載進行了優化以外，鑑於多種緣由，VoltDB仍是應用主動-主動XDCR的理想平臺。

儘管VoltDB已經啓用了被動數據庫複製功能，用以在主羣集和副本羣集之間提供並行二進制複製，可是VoltDB的Version 6發行版引入了XDCR和主動-主動數據庫複製，也能夠稱爲主動-主動複製。XDCR支持跨兩個數據庫集羣的雙向主動複製。藉助此功能，VoltDB提供了在兩個不一樣位置維護獨立且已同步的可寫數據庫的功能。

VoltDB將傳入的請求路由到肯定性隊列中，這些肯定性隊列統稱爲「命令日誌」，每一個隊列都由稱爲分區的單線程處理引擎使用。在每一個服務器上，分區和CPU內核之間一般存在1：1的關係，所以每一個內核都忙於快速處理一次事務。

在處理交易時，它們對數據庫所作的二進制更改將寫到所謂的「 Binlog」中。Binlog與傳統RDBMS中的「重作日誌」不一樣，後者僅限於描述對行的更改。相反，它包含在衝突發生時咱們須要解決的元數據：

Binlog的一個關鍵方面是它具備ACID嚴苛語義：若是我更新兩行，則Binlog要麼包含兩個更改，要麼不包含任何更改。正如咱們稍後將討論的那樣，咱們認爲這是任何XDCR系統的關鍵要求。

編寫Binlog時，它會流式傳輸到所需的目標位置。每一個分區使用一個流，這意味着咱們能夠擴展。若是站點之間的連接斷開，更改將被緩衝直到返回。

到達目的地後，它將處理多個Binlog流，並將它們所包含的更改應用於本地表（前提是它們不會引發衝突）。咱們能夠檢測到衝突，由於在XDCR模式下，咱們爲每一行存儲了最後修改的時間戳，所以能夠查看是否存在。

VoltDB在發生衝突時會作兩件事：

• 它會使用更改的時間戳並經過比較所涉及羣集的數字ID（若是時間戳相同）來自動解析它們。
• 它向事件流報告它們的存在，該事件流一般與Kafka鏈接。這意味着您能夠編寫代碼來解決衝突事件，並弄清楚如何在發生衝突的幾秒鐘內減輕後果。

以上二者都須要提供可信且可管理的主動-主動 XDCR 解決方案。VoltDB 不只知足主動-主動XDCR 的必要要求，並且咱們經過提供全部使主動-主動XDCR 運轉良好的上述全部內容，使其既可靠又具備成本效益，包括：

1.最小配置的自動化

與其餘數據庫技術產品和服務不一樣，VoltDB的「槓桿」最少。主動-主動XDCR是VoltDB的集成功能。一旦咱們的主動-主動XDCR啓動並運行，它一般會保持這種狀態。

2.始終如一的高性能

通常來講，更改在大約 400 毫秒內傳播，外加網絡時間。這 400 毫秒大體平分在確保更改記錄在源環境中的本地磁盤上、拆開目的地的流以及將更改應用於目標環境之間。

3.自動恢復

若是單個 VoltDB羣集中的節點出現故障，則從新加入時會自動從新同步。或者，能夠手動添加新的替換節點。VoltDB 將繼續爲客戶請求提供服務，而這種狀況正在進行中。從新同步節點將從倖存的節點獲取所需的數據，並將從新加入，而不會對延遲產生重大影響使用主動-主動XDCR時，恢復鏈接後，羣集會自動從新同步。

4.支持程序解決衝突

如上所述，VoltDB在處理來自其餘站點的更改流時會自動識別相互衝突的事務。衝突將被JSON化，並出如今每一個站點的導出流中，使其適合快速自動化處理。

5.嚴苛合規

主動-主動XDCR系統ACID嚴苛合規性的關鍵功能。若是開發人員不知道他們看到的是徹底衝突的交易仍是部分衝突的交易，則解決程序化衝突幾乎變得不可能。

07 實施主動-主動XDCR的真實應用案例

1.XDCR用於電信計費

電信服務提供商利用XDCR可近乎實時地管理賬戶餘額。例如，歐洲的移動運營商運行一個應用程序，該應用程序每次用戶撥打電話時都會檢查用戶的賬戶餘額。根據用戶所在的位置，請求將被路由到最近的數據中心，在該中心執行餘額檢查並迅速返回響應。XDCR負責將更改複製到遠程數據庫以進行異步備份。賬戶餘額檢查必須在200毫秒內完成，所以實施所需的等待時間極短。這些都可經過依靠VoltDB得以實現。

2.XDCR用於金融服務組織

金融服務公司也轉向XDCR，以確保事務一致性和低延遲。例如，銀行能夠在東海岸和西海岸數據中心之間實施XDCR，以支持信用卡交易。若是加利福尼亞的用戶須要得到信用卡交易的批准，而且那一刻到洛杉磯數據中心的流量很高，那麼銀行能夠經過自動將交易從新路由到其紐約數據中心來避免延遲或沒必要要的交易降低。一樣，交易中心能夠實施XDCR以確保在數據中心流量過大時在正確的時間輸入訂單。

VoltDB是惟一爲大規模主動-主動XDCR構建，而不會增長成本或損害數據準確性的數據平臺。
您看好VoltDB嗎？ 立刻行動吧！
歡迎私信，與更多小夥伴一塊兒探討。

關於VoltDBVoltDB支持強ACID和實時智能決策的應用程序，以實現互聯世界。沒有其它數據庫產品能夠像VoltDB這樣，能夠同時須要低延時、大規模、高併發數和準確性相結合的應用程序加油。VoltDB由2014年圖靈獎得到者Mike Stonebraker博士建立，他對關係數據庫進行了從新設計，以應對當今不斷增加的實時操做和機器學習挑戰。Stonebraker博士對數據庫技術研究已有40多年，在快速數據，流數據和內存數據庫方面帶來了衆多創新理念。在VoltDB的研發過程當中，他意識到了利用內存事務數據庫技術挖掘流數據的所有潛力，不但能夠知足處理數據的延遲和併發需求，還能提供實時分析和決策。VoltDB是業界可信賴的名稱，在諾基亞、金融時報、三菱電機、HPE、巴克萊、華爲等領先組織合做有實際場景落地案例。