雖然數據中心的建設規模越來越大，但也不可能無限制地擴容下去，這和數據中心所處的位置、環境、技術水平、公共設施等都有關系。很多時候，要在多地建設很多座數據中心，有時是應用的需要，有時是資源限制，也有時是為了數據備份，甚至到現在還出現了很多新鮮的概念：比如微型數據中心，云端數據中心等，不再一味地強調建設超大超強的數據中心，俗話說“三個臭皮匠頂一個諸葛亮”，未來的數據中心可以以數量取勝，而不是個體的大與小。那么問題來了，多個數據中心之間如何協調工作，才能達到“1+1大于2”的效果？這就涉及到數據中心之間的數據復制技術，必須學會用好復制技術，才能玩轉多數據中心。

單主復制技術

單主復制指的是只有一個主數據中心有數據寫權限，完成數據的寫入工作，同時向其它數據中心同步數據，其它數據中心只提供只讀服務。單主復制技術相當于將主數據中心的數據COPY多份，放到其它數據中心中，供更多人去訪問，但是這些數據只有讀權限，對于那些交互式的訪問，這種復制技術行不通。為了不影響主數據中心的寫入性能，同步數據一般采用異步方式復制，這樣由于時間上的不完全同步，當主數據中心失效時，其它數據中心的數據會有少量丟失，還有多個數據中心只有一個主數據中心執行寫數據操作，工作效率低，寫數據量少，同樣也會影響復制到其它數據中心的數據量，最終影響的是整個數據中心系統的效率。

多主復制技術

既然單主復制技術的寫數據效率太低，于是就出現了多主復制技術。多主實現了多個數據中心都可以寫數據，當然也支持讀數據。多主復制技術需要解決寫請求順序的問題，不同數據中心所處的位置不同，相同的寫操作在不同的數據中心執行的效果和時間并不同，這就容易出現數據的差異，導致寫數據錯誤或者有延遲，這是數據中心的應用所不能容忍的，這樣一般選擇在地理位置上接近的數據中心進行同時寫數據，時延可以得到保障，所以這類多主復制技術一般是部署在兩個數據中心上，由兩個位置較近的數據中心同時完成寫數據，同時兩個數據中心向其它數據中心復制數據，其它數據中心支持數據的讀訪問，如果要實現多于兩個數據中心同時寫數據，多主復制技術就不適合了。

第二階段提交技術

兩階段提交是在分布式系統上實現事務的一種協議，分布式系統的一個難點是如何保證架構下多個節點在進行事務性操作的時候保持一致性。二階段提交技術首先假設存在一個節點作為協調者，其他節點作為參與者，所有節點之間可以進行網絡通信。同時所有節點都采用預寫式日志，即使節點損壞日志數據也不會消失。二階段提交技術也適用于多數據中心之間數據復制，在數據中心里選出一個協調者，其它充當參與者，按照第二階段提交算法來實現多數據中心之間的數據復制。不過，美國云服務器 韓國vps云主機，第二階段提交技術也有很大限制，這種方案雖沒有單點錯誤，但由于額外的協調通訊，它會提高延遲，一個寫操作時間就要達到 200 毫秒的級別，深圳論壇空間 香港主機，大大降低吞吐量和增加延遲，不適用于那些對吞吐量和時延要求比較高的數據中心。在協調者數據中心在執行過程中，所有參與節點都是事務阻塞型的，當參與者發生故障，協調者需要給每個參與者額外指定超時機制，超時后整個事務失敗，沒有容錯機制，參與者可能會一直阻塞下去。如果協調者在發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了，那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否已經被提交。顯然第二階段提交技術也存在問題，當然還有第三階段提交技術，相比第二階段提交增加了超時機制，并在第一階段和第二階段之間增加了一個準備階段，保證了在最后提交階段之前各參與節點的狀態是一致的。既然第三階段提交比第二階段好，為何是第二提交階段技術總為人所提及，這是因為第三階段提交會存在數據不一致的問題，這大大限制了技術的應用。

Paxos一致性算法

Paxos是萊斯利蘭伯特于1990年提出的一種基于消息傳遞的算法，被認為是一致性算法中最為有效的一種，其解決了一個分布式系統中數據一致性問題。Paxos為保證每個節點執行相同的命令序列，需要在每一條指令上執行Paxos，以保證每個節點看到的指令一致。若在多數據中心之間部署Paxos，可以實現數據的完全一致性。將Paxos算法部署到數據中心，可以實現所有的跨數據中心一切操作，特別用來協調狀態在數據中心間轉移。如果你的應用為一個數據中心提供數據，當它需要把數據轉移到另外一個數據中心時，這些協調的工作就需要通過 Paxos ，Paxos 還會用來管理 memcache 和離線處理。因為Paxo算法中也有不少的判斷和交互過程，這直接導致的就是數據的處理時延高，讀寫效率下降，但數據基本不會丟失，并且數據中心之間的數據也完全一致。