方案背景
隨著互聯網業務快速發展，多IDC的業務支撐能力和要求也逐步提升，行業內的“兩地三中心”方案較為流行。
其中兩地是指同城、異地；三中心是指生產中心、同城容災中心、異地容災中心。
在早期，比較典型的是國內外銀行多采用“兩地三中心”建設方案。這種模式下，多個數據中心是主備關系，即存在主次，業務部署優先級存在差別，針對災難的響應與切換周期非常長，RTO與RPO目標無法實現業務零中斷，資源利用率低下，投資回報無法達到預期。兩地三中心本質上是一種通過簡單資源堆砌提高可用性的模式，對高可用的提高、業務連續性的保證仍然只是量變，業務連續性及容災備份一直沒有實質性的跨越。
目前，以銀行為代表的、包括政府、公共交通、能源電力等諸多行業用戶，開始將關注點轉向“分布式多活數據中心”
通過雙活的方案，具有兩類特點。一是多IDC中心之間地位均等，在正常模式下協同工作，并行的為業務訪問提供服務，實現了對資源的充分利用，避免一個或兩個備份中心處于閑置狀態，造成資源與投資浪費，通過資源整合，多活數據中心的服務能力往往雙倍甚至數倍于主備數據中心模式；二是在一個數據中心發生故障或災難的情況下，其他數據中心可以正常運行并對關鍵業務或全部業務實現接管，達到互為備份的效果，實現用戶的“故障無感知”。
結合公司目前的業務運營情況，IDC機房主要在xxxx,xxx,同時在xxxx區域部署有一些IDC機房，其中數據中心主要以xxx為主，所以在兩地三中心方案中，同城雙活較為符合發展的趨勢。
而兩地三中心方案的設計，不光需要數據庫層基于分布式進行改造，同時在業務層，系統層，網絡層都需要相關的方案適配。
目標和計劃：
ü 兩地三中心的設計原則為同城雙活，異地容災，其中同城暫定為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等。
歡迎大家拋磚引玉，后續跟進閱讀量考慮要不要繼續展開。：）
相關鏈接：
http://www.info2soft.com/6291.html
http://www.h3c.com/cn/d_201307/790142_30008_0.htm
