本文分享了跨資料中心狀態同步兩地三中心的理論技術，涉及資料庫相關，其中會交代「如何去做」，以及會讓大家理解「為什麼要這麼去做」。
關於分布式協議的概念。以今年的「雙十一」阿里的創造的驚人交易額為例，它的技術團隊出來做技術分享時提到一點，就是支付寶交易每秒鐘到了 8.5 萬筆，這其中有很多東西可可供分析。
這其中就包含分布式協議。全球範圍內真正能夠實現分布式一致性演算法的只有兩個：乙個是 paxos，另乙個是 raft。paxos 擁有很長的歷史，它最早是谷歌實現的。2023年，有兩位教授發表了一篇**叫做raft，非常值得去學習。**中有乙個組建使用的也是paxos 的演算法。要真正實現分布式資料狀態協議的話，一般會選擇paxos 和raft。從容易實現的角度考慮的話，就採用raft。
途牛最初的系統都在南京，但為了照顧使用者體驗，公司就將**遷到了北京。原因是技術團隊進行了呼叫，發現其中存在很多問題，包括遠距離跨機房同步問題，以及專線穩定性對服務質量的影響。一般的系統網路都是 4 個9 或以上，還有寬頻擠占、各個系統呼叫等，還有下面要具體講的資料庫同步延時。
途牛的後台系統允許客戶註冊，在**上註冊可以選擇南京或北京。技術團隊選擇南京，是因為更多的使用者集中在南京這邊。如果註冊時到北京去，我們讀的就是北京資料庫。而一旦出現延時就無法登入，這樣使用者體驗是非常糟糕的。除此之外，就是不能做強一致性高可用。如果在兩地做，萬一出問題需要切換，資料可能會丟失，這需要極力避免。
關於「cap」，很多人都了解它的含義，就是一致性、可用性、分割槽容錯性。但這三者不可兼得，因此分割槽是必然的。對電商來說，它對資料的要求比較高，所以選擇consistency（一致性）。
上圖中的重合區域只有乙個「小三角」，它說明這個資料很難落地，三者的優點很難兼顧。因此看上去 cap 能夠滿足需求的，而實際情況並不是這樣。
上文提到，途牛的選擇是針對當前的這種開源，或者是技術實現。技術團隊現在用開源資料庫，來實現：
主從複製、做高可用；
防止丟失資料；
只犧牲一定的效能，等待資料被同步。
但遠距離機房延時太大，從而影響了系統吞吐量，所以決定做了機房搬遷。今年公司把整個北京機房搬遷到了南京，與主要系統合為一處。
上面的，相信很多人都見過。途牛的應用是先向資料庫發起事務，這個事務完成後，它會寫到日誌裡面，然後返回應用。
這種專線最終落地是什麼？就是光纖傳輸。可以算一下它的傳輸效能：真空中光速30萬千公尺/s，光纖材質折射率 1.45 左右，全反射傳輸，路徑大於光纖長度，折算下來小於20km/0.1ms，如果算同城的話，是1000ms / 0.2ms=5000（tps）。可以通過技術提公升這個速度，這與業務具體架構相關。
南京到北京，距離近千公里，光纖不會是直線布置，中間會包含很多的彎和網路裝置。在這種情況下，南北傳輸，可以達到 1000ms / 50ms=20（tps）水平。
之前途牛會員系統的後台並不完善。有時會被使用者刷會員，甚至被刷壞掉。當時系統支援的事務量很小，這個情況跟創業公司有點類似：在高速發展階段，團隊整體的效率沒那麼高，但為了降低成本，可能會讓乙個功能快速上線，但中間如何優化、如何實現都沒有考慮過。這樣的系統，經過多年累積，其中就會出現了很多問題。後來，技術團隊使用了非同步的方式解決了這個問題。
ha 組建及雙中心 ha 缺陷。這裡面有 heartbeat、keepalived等，也是一樣的，但是缺少第三方仲裁，會導致「腦裂」，特別在偶數的下面。如果兩部分都正常，可能會引起資料不一致，進而造成資料丟失等。一般來說，會選擇f=1，或者是2，就是5個節點，我們選用比較成熟的解決方案。還有很多 15 節點的方案，進一步提高了可能性，它允許兩個節點失效。
雙中心ha缺少仲裁，因此途牛選擇三中心ha。三中心有仲裁，三個節點，至少不會發生「腦裂」的現象。這三中心的分布是「同城加異地」，這比較容易理解：同城可以保證一定的吞吐量——同城資料中心降低的同步延時，低延時極大提公升了吞吐量，第三資料中心參與選擇仲裁及災備恢復。出於安全考慮，第三中心一般距離會比較遠。比如在南京的機房會遠一點，就是為了避免出現**等自然災害同時影響三個中心的情況發生。
吞吐量提公升，是可以採用各種各樣的方法來實現的。阿里雙十一的峰值可以達到8萬5千筆/秒的交易。他們引以為傲的，是去年只有 10% 的交易在oceanbase，而今年在 100% 都遷到cceanbase。這是如何實現的？sharding 分割槽是避免不了的。採用發號器避免衝突，實現高併發，分區間用 2pc 實現分布式事務。這其中還涉及到全域性，還有部分採用佇列非同步處理。做全域性索引對業務影響並不大，因此一般統計的時候，往往通過非同步去實現。