雖然數據中心的建設規模越來越大，但也不可能無限制地擴容下去，這和數據中心所處的位置、環境、技術水平、公共設施等都有關係。很多時候，要在多地建設很多座數據中心，有時是應用的需要，有時是資源限制，也有時是為了數據備份，甚至到現在還出現了很多新鮮的概念：比如微型數據中心，雲端數據中心等，不再一味地強調建設超大超強的數據中心，俗話說“三個臭皮匠頂一個諸葛亮”，未來的數據中心可以以數量取勝，而不是個體的大與小。那麼問題來了，多個數據中心之間如何協調工作，才能達到“1+1大於2”的效果?這就涉及到數據中心之間的數據複製技術，必須學會用好複製技術，才能玩轉多數據中心。
單主複製技術
單主複製指的是隻有一個主數據中心有數據寫權限，完成數據的寫入工作，同時向其它數據中心同步數據，其它數據中心只提供只讀服務。單主複製技術相當於將主數據中心的數據COPY多份，放到其它數據中心中，供更多人去訪問，但是這些數據只有讀權限，對於那些交互式的訪問，這種複製技術行不通。為了不影響主數據中心的寫入性能，同步數據一般採用異步方式複製，這樣由於時間上的不完全同步，當主數據中心失效時，其它數據中心的數據會有少量丟失，還有多個數據中心只有一個主數據中心執行寫數據操作，工作效率低，寫數據量少，同樣也會影響複製到其它數據中心的數據量，最終影響的是整個數據中心繫統的效率。
多主複製技術
既然單主複製技術的寫數據效率太低，於是就出現了多主複製技術。多主實現了多個數據中心都可以寫數據，當然也支持讀數據。多主複製技術需要解決寫請求順序的問題，不同數據中心所處的位置不同，相同的寫操作在不同的數據中心執行的效果和時間並不同，這就容易出現數據的差異，導致寫數據錯誤或者有延遲，這是數據中心的應用所不能容忍的，這樣一般選擇在地理位置上接近的數據中心進行同時寫數據，時延可以得到保障，所以這類多主複製技術一般是部署在兩個數據中心上，由兩個位置較近的數據中心同時完成寫數據，同時兩個數據中心向其它數據中心複製數據，其它數據中心支持數據的讀訪問，如果要實現多於兩個數據中心同時寫數據，多主複製技術就不適合了。
第二階段提交技術
兩階段提交是在分佈式系統上實現事務的一種協議，分佈式系統的一個難點是如何保證架構下多個節點在進行事務性操作的時候保持一致性。二階段提交技術首先假設存在一個節點作為協調者，其他節點作為參與者，所有節點之間可以進行網絡通信。同時所有節點都採用預寫式日誌，即使節點損壞日誌數據也不會消失。二階段提交技術也適用於多數據中心之間數據複製，在數據中心裡選出一個協調者，其它充當參與者，按照第二階段提交算法來實現多數據中心之間的數據複製。不過，第二階段提交技術也有很大限制，這種方案雖沒有單點錯誤，但由於額外的協調通訊，它會提高延遲，一個寫操作時間就要達到 200 毫秒的級別，大大降低吞吐量和增加延遲，不適用於那些對吞吐量和時延要求比較高的數據中心。在協調者數據中心在執行過程中，所有參與節點都是事務阻塞型的，當參與者發生故障，協調者需要給每個參與者額外指定超時機制，超時後整個事務失敗，沒有容錯機制，參與者可能會一直阻塞下去。如果協調者在發出commit消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了，那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否已經被提交。顯然第二階段提交技術也存在問題，當然還有第三階段提交技術，相比第二階段提交增加了超時機制，並在第一階段和第二階段之間增加了一個準備階段，保證了在最後提交階段之前各參與節點的狀態是一致的。既然第三階段提交比第二階段好，為何是第二提交階段技術總為人所提及，這是因為第三階段提交會存在數據不一致的問題，這大大限制了技術的應用。
Paxos一致性算法
Paxos是萊斯利蘭伯特於1990年提出的一種基於消息傳遞的算法，被認為是一致性算法中最為有效的一種，其解決了一個分佈式系統中數據一致性問題。Paxos為保證每個節點執行相同的命令序列，需要在每一條指令上執行Paxos，以保證每個節點看到的指令一致。若在多數據中心之間部署Paxos，可以實現數據的完全一致性。將Paxos算法部署到數據中心，可以實現所有的跨數據中心一切操作，特別用來協調狀態在數據中心間轉移。如果你的應用為一個數據中心提供數據，當它需要把數據轉移到另外一個數據中心時，這些協調的工作就需要通過 Paxos ，Paxos 還會用來管理 memcache 和離線處理。因為Paxo算法中也有不少的判斷和交互過程，這直接導致的就是數據的處理時延高，讀寫效率下降，但數據基本不會丟失，並且數據中心之間的數據也完全一致。
表1列了幾種複製技術的對比差異，各有各的優缺點，要看數據中心最為關注的是哪個方面，選擇最適合自己的數據中心數據複製技術。
相關推薦
