去哪兒黃勇：去哪網數據庫架構發展歷程

  2005年2月，去哪兒在北京成立，去哪兒網的數據庫也搭建完成。去哪兒網數據庫架構師黃勇在SACC大會現場打趣道，那時的數據庫就是一個小作坊模式，單機房內的MySQL架構。在這之后，去哪兒網數據庫架構共經歷了四個階段，逐漸過渡到今天的跨機房QMHA架構，可異地部署還可保證高可用和安全性。這一路走來，是什么推動了去哪兒網的數據庫架構變遷?又遇到了哪些問題?如何解決的呢?

　　Qunar萌芽與發展期—單機房內的MySQL到單機房內的MMM

　　業務發展和技術都相對不太發達的過去，MMM架構是非常受歡迎的一種部署方式，當時廣泛應用于各大公司內部。黃勇表示，隨著業務發展，這種簡單的MMM架構逐漸暴露出了許多問題，比如運維復雜，需要綁定VIP，部署和修改配置文件，周邊監控工具也十分匱乏。其次，網絡分區也存在很大問題，Master“假死”導致誤切換，數據庫雙寫導致數據錯亂，VIP沒有漂移或者漂移失敗等。

　　2012年，MySQL 5.6以上版本新特性開始不支持，這也標志著MMM時代的徹底結束。

　　Qunar飛速發展期—同機房PXC架構

　　隨著業務的急速增長，推動了架構的又一次革新。去哪兒網開始應用PXC架構，新加入了哨兵集群，此時的架構已經可以自動failover、手動switchover、讀寫分離、負載均衡、namespace服務，全局唯一、透明、擴容、遷移和升級。PXC單節點讀取可達5W qps，寫入可達15K qps。

　　去哪兒網之所以后來會放棄PXC選擇QMHA，還是因為PXC自身存在一定的局限性。比如節點間機器木桶短板效應、客戶端容易雪崩;大事務和密集事務導致PXC節點壓力高，fc產生;DDL操作會殺死其他事務，但DDL不能取消;相互校驗導致寫入性能下降，切換時不影響前端寫入，但盡量不要長時間多寫;機房間網絡延遲高影響客戶端QPS，且機器節點越多，QPS影響越大;PXC和MGR等新興結構導致DBA學習成本變高，需要長期的學習和經驗才可以掌握。

　　Qunar平穩期—跨機房QMHA架構

　　2015年至今，去哪兒網采用跨機房QMHA架構。GTID易于維護和切換，主從節點間可知數據差異，分布式哨兵減少誤切換和網絡分區raft算法，提高數據節點一致性的同時提高集群安全性和可用性，多線程復制且可以跨機房和網段部。全局namespace通知客戶端更新配置。

　　黃勇表示，日后跨機房QMHA架構會逐漸解決自動補全binlog、延遲處理和權重控制等問題，MHA可以自動補全binlog，PXC可以IST QMHA需要能在failover后自動補全binlog給原master節點，PXC和QMHA都需要做到只讀數據源可以根據權重配比進行流控，有助于對特殊機器的特殊處理。

　　經歷了四個階段的發展，去哪兒網的數據庫架構日趨穩定，足以滿足日常業務所需。去哪兒網開發的DBA操作平臺—補天融合了去哪兒網數據庫整個團隊的經驗和智慧，如果你感興趣，不妨來試試!