隨着互聯網業務快速發展，多IDC的業務支撐能力和要求也逐步提升，行業內的“兩地三中心”方案較爲流行，今天爲您介紹一下到底這是什麼？
其中兩地是指同城、異地；三中心是指生產中心、同城容災中心、異地容災中心。
在早期，比較典型的是國內外銀行多采用“兩地三中心”建設方案。這種模式下，多個數據中心是主備關係，即存在主次，業務部署優先級存在差別，針對災難的響應與切換週期非常長，RTO與RPO目標無法實現業務零中斷，資源利用率低下，投資回報無法達到預期。兩地三中心本質上是一種通過簡單資源堆砌提高可用性的模式，對高可用的提高、業務連續性的保證仍然只是量變，業務連續性及容災備份一直沒有實質性的跨越。
目前，以銀行爲代表的、包括政府、公共交通、能源電力等諸多行業用戶，開始將關注點轉向“分佈式多活數據中心”
通過雙活的方案，具有兩類特點。
一是多IDC中心之間地位均等，在正常模式下協同工作，並行的爲業務訪問提供服務，實現了對資源的充分利用，避免一個或兩個備份中心處於閒置狀態，造成資源與投資浪費，通過資源整合，多活數據中心的服務能力往往雙倍甚至數倍於主備數據中心模式；二是在一個數據中心發生故障或災難的情況下，其他數據中心可以正常運行並對關鍵業務或全部業務實現接管，達到互爲備份的效果，實現用戶的“故障無感知”。複製代碼
結合公司目前的業務運營情況，IDC機房主要在xxxx,xxx,同時在xxxx區域部署有一些IDC機房，其中數據中心主要以xxx爲主，所以在兩地三中心方案中，同城雙活較爲符合發展的趨勢。
而兩地三中心方案的設計，不光需要數據庫層基於分佈式進行改造，同時在業務層，系統層，網絡層都需要相關的方案適配。
兩地三中心5種解決方案介紹
目標和計劃：
-
兩地三中心的設計原則爲同城雙活，異地容災，其中同城暫定爲HB30,HB21,異地容災暫定爲華中或華東的IDC節點
-
改造設計需要和業務端進行密切配合，從業務場景出發選擇合適的方案
-
考慮跨機房的支持，需要引入consul方案，實現service_name的高可用管理
-
同城雙活的數據要求爲最終一致性，異地容災暫不對業務開放，在30分鐘內可以快速恢復業務
-
可以設定短期目標和長期目標，短期目標可以充分藉助開源紅利和業務場景進行落地，在落地過程中不斷的迭代改進；長期目標可以選擇更爲通用，技術挑戰較大，業務效果好的方案（如異地多活）。
-
爲了確保方案的有效，需要定期進行演練
方案簡介
兩地三中心方案中，基於設定的短期目標可以明確同城雙活和異地容災的方案組合。
則設計重點爲同城雙活，即在同城的數據中心之間，一般通過高速光纖相連，在網絡帶寬有保障的前提下，網絡延遲一般在可接受範圍內，兩個機房之間可以認爲在同一個局域網內。
在設計上可以和應用層結合起來，有兩種部署模式：分爲應用層雙活和數據庫雙活，應用層雙活和數據庫單活。
1）.應用層雙活和數據庫單活方案：
應用層雙活，數據庫單活：兩個機房的應用程序同時對外提供服務，但是隻有一個機房的數據庫提供讀寫，另外一個機房的應用程序需要跨機房訪問數據庫，數據庫之間單向複製。該模式在網絡延遲相對低的同城環境下表現良好，但是如果距離超過100 公里，機房之間的網絡延遲就會超過2ms（或者更高），此時對於跨機房訪問的數據庫請求，性能有較大影響。
針對同城網絡延遲低，可以看作是同一個局域網的特點，對於應用雙活+數據庫單活的方案，應用跨機房訪問數據庫，一旦某個機房故障，則將另外一個機房的應用訪問請求切換到本機房的數據庫，從而實現同城任何一個數據中心出現故障，都不會影響到整體業務的運行。
由於同城之間網絡條件相對較好，MySQL 數據庫原生的複製模式能夠滿足大部分業務場景，MySQL 5.7 推出的並行複製可以有效解決容災機房日誌回放慢的問題，在5.7.17推出的MGR/InnoDB Cluster則可以實現數據的強一致需求。
方案一：MGR集羣多活架構
整個架構是基於分佈式方案來設計，節點通信基於協議Paxos，MGR作爲InnoDB Cluster的核心組件，目前支持單主模式和多主模式，本方案優先採用單主模式，節點數至少2-9個節點。
基於MGR的多活的設計方案如下，在數據庫層通過優先在本機房的實例節點設置權重，優先切換到同機房，在同機房出現故障的情況下，切換到同城異機房。
以上方案的實施成本較低，對業務的侵入較少，適用於跨機房容災的初級階段的用戶。
2） 應用層雙活，數據庫雙活方案
應用層雙活和數據庫雙活：兩個機房的應用程序同時對外提供服務，兩個機房的數據庫也同時提供讀寫，每個機房的應用程序讀寫同一個機房內的數據庫，兩個數據庫之間雙向複製，通過一致性協議解決雙向寫衝突問題，該模式理論上實現了數據庫多點寫入，但是在實際跨機房場景中，尤其是在寫衝突密集的業務場景下，性能下降非常大，不適用於跨機房的OLTP 系統。
而對於應用雙活+數據庫多活的方案，需要重點考慮數據延遲和數據同步的問題。首先需要在業務上做隔離，數據目標爲最終一致性，目前存在如下的五類方案。
方案一：MGR集羣多活架構
可以基於MGR的多活特性，數據的寫入可以在多個節點之間進行復制，實現數據強一致性需求，並且在節點間通信出現延遲的情況下，會自動實現服務降級。
對於此類方案，我們可以採用同機房多寫，同城異機房只讀的方案。
方案二：分佈式數據同步
基於分佈式設計方案，可以引入數據組件syncer和writer,實現機房多活的業務需求，syncer和writer爲數據的發佈者和消費者，基於分佈式協議進行處理。
在處理過程中有三類關鍵技術：
1）數據的處理基於分佈式ID，能夠唯一定位數據處理操作，並且該操作具備遞增趨勢。
2）同步組件的穩定性，同步組件可以理解爲一種通用服務，需要考慮不同機房間的數據延遲和數據衝突處理機制，保證同步組件服務的穩定，高效。
3）同步組件的高可用，對於同步組件需要根據業務特點做權重處理，考慮不通IDC的業務情況，並重點考慮同步組件的數據冗餘設計，保證發生異常時能夠及時恢復數據。
此種方案短期內難以實現，但是長期來看，可以支持機房多活，業務價值更高。
方案三：雙主模式的多活
對於數據庫原生的雙主模式，兩個節點均可以寫入數據，可以實現跨機房的數據複製，延遲較低，在業務層需要做隔離，在故障發生時能夠快速切換到同機房的Slave節點。
此方案對於兩個IDC機房的場景中較爲實用，但是機房多活的場景不適合。
方案四：業務交叉的雙活方案
此種方案是雙活技術的變通實現，即存在兩類業務A和B,數據存儲在database級別（schema層級），分別在不通的IDC節點完成數據寫入，比如業務A在IDC1完成寫入，業務B在IDC2完成寫入，兩個節點之間存在跨機房的複製節點，在出現問題時，能夠通過域名的方式切換到指定的IDC節點。
此種方案對於業務的依賴性較高，不適合機房多活的場景。
方案五：基於NewSQL的改造方案
可以參考行業內的NewSQL開源解決方案，原生支持MySQL協議。
比如PolarDB,Sequoia，TiDB等。
作者：AskHarries
鏈接：https://juejin.im/post/5ef016e3e51d45740850fb95