為什麼主動跨資料複製在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嗎？ 馬上行動吧！
歡迎私信，與更多小夥伴一起探討。

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