本文分享了跨資料中心狀態同步兩地三中心的理論技術，涉及資料庫相關，其中會交代“如何去做”，以及會讓大家理解“為什麼要這麼去做”。

分散式協議/概念

關於分散式協議的概念。以今年的“雙十一”阿里的創造的驚人交易額為例，它的技術團隊出來做技術分享時提到一點，就是支付寶交易每秒鐘到了 8.5 萬筆，這其中有很多東西可可供分析。

這其中就包含分散式協議。全球範圍內真正能夠實現分散式一致性演算法的只有兩個：一個是 Paxos，另一個是 Raft。Paxos 擁有很長的歷史，它最早是谷歌實現的。2012年，有兩位教授發表了一篇論文叫做Raft，非常值得去學習。論文中有一個組建使用的也是Paxos 的演算法。要真正實現分散式資料狀態協議的話，一般會選擇Paxos 和Raft。從容易實現的角度考慮的話，就採用Raft。

遠距離跨機房同步問題

途牛最初的系統都在南京，但為了照顧使用者體驗，公司就將網站遷到了北京。原因是技術團隊進行了呼叫，發現其中存在很多問題，包括遠距離跨機房同步問題，以及專線穩定性對服務質量的影響。一般的系統網路都是 4 個9 或以上，還有寬頻擠佔、各個系統呼叫等，還有下面要具體講的資料庫同步延時。

途牛的後臺系統允許客戶註冊，在網站上註冊可以選擇南京或北京。技術團隊選擇南京，是因為更多的使用者集中在南京這邊。如果註冊時到北京去，我們讀的就是北京資料庫。而一旦出現延時就無法登入，這樣使用者體驗是非常糟糕的。除此之外，就是不能做強一致性高可用。如果在兩地做，萬一出問題需要切換，資料可能會丟失，這需要極力避免。

CAP 中，我們的選擇

關於“CAP”，很多人都瞭解它的含義，就是一致性、可用性、分割槽容錯性。但這三者不可兼得，因此分割槽是必然的。對電商來說，它對資料的要求比較高，所以選擇Consistency（一致性）。

上圖中的重合區域只有一個“小三角”，它說明這個資料很難落地，三者的優點很難兼顧。因此看上去 CAP 能夠滿足需求的，而實際情況並不是這樣。

上文提到，途牛的選擇是針對當前的這種開源，或者是技術實現。技術團隊現在用開源資料庫，來實現：

1. 主從複製、做高可用；
2. 防止丟失資料；
3. 只犧牲一定的效能，等待資料被同步。

但遠距離機房延時太大，從而影響了系統吞吐量，所以決定做了機房搬遷。今年公司把整個北京機房搬遷到了南京，與主要系統合為一處。

資料的傳輸

上面的圖片，相信很多人都見過。途牛的應用是先向資料庫發起事務，這個事務完成後，它會寫到日誌裡面，然後返回應用。

這種專線最終落地是什麼？就是光纖傳輸。可以算一下它的傳輸效能：真空中光速30萬千米/S，光纖材質折射率 1.45 左右，全反射傳輸，路徑大於光纖長度，折算下來小於20KM/0.1MS，如果算同城的話，是1000ms / 0.2ms=5000（TPS）。可以通過技術提升這個速度，這與業務具體架構相關。

南京到北京，距離近千公里，光纖不會是直線佈置，中間會包含很多的彎和網路裝置。在這種情況下，南北傳輸，可以達到 1000MS / 50MS=20（TPS）水平。

基於 HA 的資料中心繫統構建

之前途牛會員系統的後臺並不完善。有時會被使用者刷會員，甚至被刷壞掉。當時系統支援的事務量很小，這個情況跟創業公司有點類似：在高速發展階段，團隊整體的效率沒那麼高，但為了降低成本，可能會讓一個功能快速上線，但中間如何優化、如何實現都沒有考慮過。這樣的系統，經過多年累積，其中就會出現了很多問題。後來，技術團隊使用了非同步的方式解決了這個問題。

雙十一阿里如何做到8萬5千筆/秒的交易頻率的？最早從騰訊開始，通過 QQ 號取模的方式，其中道理是一樣的。一個整體，如果是序列，它的分佈量是比較有限的。前文提到的 0.2 毫秒，而理論上只能達到 5 千每秒，如何去提升呢？在程式設計上面要作調整，當效能發展到一定規模後，需要提升整個系統吞吐量，就必須考慮低層的架構，哪怕谷歌也是一樣：曾經谷歌發現這裡面數據庫識別越來越多，各種不可用，谷歌就把系統遷移到自己開發。這麼大的資料量怎麼去做？如下圖中所述。

HA 組建及雙中心 HA 缺陷。這裡面有 heartbeat、keepalived等，也是一樣的，但是缺少第三方仲裁，會導致“腦裂”，特別在偶數的下面。如果兩部分都正常，可能會引起資料不一致，進而造成資料丟失等。一般來說，會選擇F=1，或者是2，就是5個節點，我們選用比較成熟的解決方案。還有很多 15 節點的方案，進一步提高了可能性，它允許兩個節點失效。

雙中心HA缺少仲裁，因此途牛選擇三中心HA。三中心有仲裁，三個節點，至少不會發生“腦裂”的現象。這三中心的分佈是“同城加異地”，這比較容易理解：同城可以保證一定的吞吐量——同城資料中心降低的同步延時，低延時極大提升了吞吐量，第三資料中心參與選擇仲裁及災備恢復。出於安全考慮，第三中心一般距離會比較遠。比如在南京的機房會遠一點，就是為了避免出現地震等自然災害同時影響三個中心的情況發生。

吞吐量提升，是可以採用各種各樣的方法來實現的。阿里雙十一的峰值可以達到8萬5千筆/秒的交易。他們引以為傲的，是去年只有 10% 的交易在Oceanbase，而今年在 100% 都遷到Cceanbase。這是如何實現的？Sharding 分割槽是避免不了的。採用發號器避免衝突，實現高併發，分割槽間用 2PC 實現分散式事務。這其中還涉及到全域性，還有部分採用佇列非同步處理。做全域性索引對業務影響並不大，因此一般統計的時候，往往通過非同步去實現。

最後總結一下。根據只是把邏輯思維展現出來；兩地三中心一定是同城，因為要保證它的吞吐量、保證業務可用性，如果選擇 CP （一致性&分割槽容錯性）可能達不到理想的效果。三中心對應狀態同步的三節點，兩地是照顧到安全和效能。另外，需要把第三個機房放到異地或者比較遠的地方去。（責編/錢曙光）