攜程資料庫高可用和容災架構演進
作者簡介
郜德光，攜程技術保障中心高階資料庫經理，負責資料庫相關的運維工作，參與了SQL Server和MySQL的高可用以及資料庫容災建設。喜歡鑽研技術，對資料相關的技術一直保持著濃厚的興趣。
網站穩定性對任何一家公司來說都至關重要。業務長時間中斷，不僅僅意味著收入的損失，更可能會失去客戶。資料庫的穩定性和HA/DR建設是網站高可用建設非常重要的一個環節。
本文分享了攜程資料庫（SQL Server，MySQL和Redis）的高可用和容災的重構歷程，以及重構的原因。也會簡單分享一下DR切換工具，該工具可以一鍵將主站資料庫切換到DR站點，用於在主站IDC故障時，快速恢復資料庫服務。
1.0時代【1999~2008】
自攜程1999年成立到2008年左右，公司資料庫產品主要是SQL Server。
這個階段是公司初創和快速發展時期，以優先發展業務為主。資料庫的架構設計比較簡單。高可用通過資料庫的映象技術來實現。映象主要的架構如下圖所示。甚至為了節省伺服器資源，我們採用多個主資料庫共享一個輔助資料庫伺服器的方式。
這種映象方式搭建和運維都比較簡單。主機如果出現故障，先嚐試重啟能否解決，如果不能恢復，則通過映象切換的方式，切換資料庫服務到從機。
這種HA架構比較簡單、粗糙，優點是不需要群集和共享儲存等資源，成本低。缺點是主機故障時沒法自動轉移，業務恢復速度較慢，嚴格來講還不具備HA的能力。
前期對於支撐當時業務發展來說已經夠了，隨著後期業務快速發展，已經無法滿足業務穩定性的需要。
2.0時代【2008~2012】
這一階段，業務進入快速發展階段，對資料庫的依賴也越來越重。開始大量採用SAN共享儲存來存放資料。單臺數據庫已無法支撐業務的壓力，因此，也對資料庫架構進行調整，引入了複製分發，用於讀寫分離。
架構如下圖所示：產品的價格首先錄入到錄入資料庫。通過SQL Server自有的表級別的複製分發技術，把資料傳遞到多個產品資料庫，以供業務訪問。如果業務訪問壓力大，則通過新增產品查詢伺服器的方式來進行擴容。
對於非讀寫分離場景的資料庫，高可用是通過Failover Cluster群集方式。DR依舊採用資料庫映象的方式。
如下圖所示：一旦伺服器主節點硬體故障，則會通過自動故障轉移，轉移業務到服務備節點，切換時間大概在2分鐘左右。主備伺服器都連線後臺共享儲存。
同時，還對資料庫服務搭建了映象，一旦儲存發生故障，主備服務節點都不可用的情況下，則通過切換映象到映象伺服器上，映象服務本身也是一個Failover Cluster群集，也做了高可用。
由於SQL Server的映象伺服器平時是不可讀的，我們還通過一個日誌傳輸服務，搭建了只讀資料庫，以供BI取數或查詢。這個只讀資料庫也用於驗證資料庫備份的有效性。
由於業務的需求越來越複雜，資料庫的架構開始逐漸複雜起來，主要體現在：
1、複製分發架構過於複雜，如城市表，基本上所有部門都需要使用，通過拉複製分發鏈路，把城市列表資訊傳遞給其他部門的資料庫，能快速解決問題，但隨之而來，使得資料庫的關係變成蜘蛛網狀。維護起來相當困難。
2、過於依賴底層的SAN儲存。SAN儲存內含相當複雜的儲存技術和網路技術，複雜一點的問題就需要依賴供應商來解決。
2012年，微軟推出了AlwaysOn高可用性組，可以不依賴於共享儲存。AlwaysOn高可用性組同時也具備讀寫分離的功能，而且也能做容災。所以，我們逐漸朝AlwaysOn這個架構演進，並用SSD來代替SAN儲存。
3.0時代【2012~2014】
在2014年左右AlwaysON技術已經非常成熟，對於多IDC環境下支援也已經非常好，是SQL Server主流的HA/DR方案解決方法。
因此在2014年後，我們開始逐步把SQL Server改造為Always ON架構。架構如下圖所示：寫還是一個節點，但可提供多個節點的讀。並且其中的一個節點是同步模式，用於做寫節點的高可用。
純AG架構
上面新的架構非常靈活。由於2014版本已經支援8個只讀副本，AlwaysOn延遲又低，因此完全解決了群集+映象架構中遇到的複製分發讀寫分離架構瓶頸的問題，同時也不在需要為離線查詢和ETL取數部署單獨的只讀資料庫。讀副本的備份功能也大大降低了備份時主機的壓力。
在推進Always ON新架構過程中，我們也逐步用SSD來取代原有的SAN。除了SSD的價格越來越便宜容量越來越大，相比SSD，SAN儲存對DBA基本是黑盒子，需要專業的運維團隊支援，運維成本更高。
4.0時代【2014~2018】
SQLServer AlwaysON技術比較成熟，但其存在一個關鍵的問題，在於AlwaysON技術是閉源的。DBA難以深入瞭解該技術的底層細節。雖然脫離了SAN儲存的依賴，但還是依賴於Windows的Failover Cluster叢集。
因此，2012年開始在攜程內部逐步推廣開源的MySQL和Redis 。在推廣MySQL的時候，我們意識到MySQL的效能比不上SQL Server, 所以同時推廣資料庫分庫分表方案和前端Redis快取。
MySQL的高可用和DR是通過MHA（Master High Availability）來實現的。具體架構如下：
通過MHA管理節點，來監聽主節點的可用性情況，一旦發現主機不可訪問，則切換到slave節點。MHA的高可用模式，既兼顧到高可用，也兼顧到DR。對於讀寫分離的需求，主要是通過分庫分表方案來進行的。部分有采用讀寫分離。
對於MHA的方式，是通過域名/虛擬IP的方式，提供給業務使用。其最大的風險的是腦裂。主機沒完全掛死，同時主從切換後，新的主機開始提供業務訪問，就產生了腦裂。為了解決這個問題，我們在資料庫訪問層，引入了動態資料來源技術，不通過域名/虛擬IP的方式，而是通過實IP的方式。提供業務訪問，有效的降低了腦裂的風險，同時不通過域名解析，能加快主從/DR切換時間。
隨著MySQL的引入，Redis也逐漸廣泛使用起來。由於Redis的Key/Value訪問速度非常快，目前攜程對Redis的依賴比對資料庫還重要。Redis本身需要有高可用和DR的方案。
對於Redis，藉助框架部門開發的中介軟體CRedis，用於Redis的訪問和高可用控制。
簡要架構如下圖所示：
說明如下：
1、業務訪問的時候，通過引用框架的客戶端元件讀取配置資訊。Redis切換由哨兵發起，並且Credis配置能及時捕獲，並通知客戶端IP和埠的變化。
2、對Redis拆分多個Group，以避免訪問熱點。每個Group包含多個Redis例項。
3、Redis例項Master/Slave在一個機房， 另外兩個例項Slave-DR在另個機房。
4、訪問請求通過CRedis配置路由到指定的分片。
5、Slave-DR例項和主例項的資料同步通過框架同步工具XPipe來實現。XPipe 已經開源，更多資訊請訪問：https://github.com/ctripcorp/x-pipe。
為應對日常DR演練以及硬體故障時快速恢復業務的場景，DBA設計開發了集中、一鍵式DR自動化切換工具，支援所有資料庫產品。用來幫助DBA快速、安全的完成資料庫切換。
DR切換工具支援不同的切換維度，覆蓋了所有的場景：
1、單個或多個數據庫群集，應對單機故障或日常維護等場景；
2、單個業務線下所有資料庫群集，應對DR切換演練場景；
3、IDC下所有資料庫群集，應對主IDC故障場景；
目前為止已經利用DR工具成功完成了200+次的切換演練。下面是用DR工具準備單群集切換的一個例子：
如上圖所示，工具中搜索到對應的群集後，工具會根據元資料資訊展示群集的整體架構：節點（名字、IP地址等）、IDC、複製關係。
每個節點提供2種切換方式：
1、強切工單，強制切換。主機或主站down時，可能有資料丟失；
2、演練工單，正常切換。主機可用時，演練或計劃內主機維護時使用；
生成的工單後續可以自動執行。
DBA把DR複雜的切換恢復流程全部整合工具裡面，工具同時支援API根據不同維度快速批量生成切換工單，支援併發切換，可以快速完成業務的切換恢復。
為保證DR工具的高可用性，在設計DR工具時也消除了工具對單個IDC的依賴。只要保證一個IDC可用，就可以通過工具發起切換。
從以上架構的演變過程，我們可以看到是從簡單 à 複雜 à 簡單的一個演變趨勢，但是穩定性和可用性有了質的飛越。 資料層本身變得越來越簡單，而擴充套件了大量的輔助架構，來提升自動化運維能力。
希望以上的分享對大家有所幫助。
【推薦閱讀】
-
ofollow,noindex"> 攜程機票日誌追蹤系統架構演進
11月23日上海，
攜程首屆技術峰會，
一起來聚~
戳下圖瞭解詳情
↓↓↓
