歐洲最大MySQL用戶之一，Booking.com資料庫構架探秘！
導語
本文根據吳鑫老師在2018年5月10日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。
吳鑫 Booking.com資料庫工程師Team Lead
2015年加入總部位於阿姆斯特丹的Booking.com數據團隊，現任資料庫工程師團隊負責人，主要是負責Booking.com里MySQ相關的運營和研發。具有超過10年MySQL的工作經驗，曾經在瑞典擔任資料庫顧問，解決不同公司的MySQL問題。
摘要：Booking.com於1996年成立於荷蘭阿姆斯特丹，是全球規模最大的酒店預訂網站之一，隸屬於Booking Holdings Inc.（納斯達克上市公司：BKNG），擁有超過160萬家住宿合作夥伴，遍布全球229個國家和地區，日均客房預訂量超過150萬間。
Booking.com使用MySQL做為主要的資料庫解決方案，目前是歐洲最大的MySQL用戶之一。本文主要會分享Booking.com的資料庫構架？如何實現資料庫的高可用性，如何自動化維護和管理大數量級的伺服器， 以及如何實現測試環境每日更新億萬數量級的在線數據。
Booking.com資料庫構架
Booking.com的MySQL約有數千台伺服器，上百個集群，多個數據中心。 數據中心同時實現了異地容災和異地多活。數據中心間的切換隻需要數十秒的時間
上圖是我們一個比較常規的MySQL集群構架圖. 一個數據鏈一般分為三層，最上層是主伺服器，下面是IM(Intermediate Master),拖帶著不同的從伺服器。
之所以會分成三個層級是因為兩個原因：
首先為了滿足異地容災的需求，各個數據中心必須要有一套完整的複製鏈路以確保程序持續穩定的運行，所以需要配備兩個以上的IM。
另一個原因是網路帶寬的限制。我們的集群小的只有5-10台伺服器，大的有200-300台伺服器。目前單個伺服器的標準網路帶寬是10G。大家知道Master slave是通過binlog傳輸的，如果一個IM下掛載太多的從伺服器，會直接用掉所有的網路帶寬，所以我們用多個IM來進行網路帶寬的分流。我們所有伺服器的硬體配置都是一樣的，這樣的優勢是主伺服器宕機後，任何一台從伺服器都能升級成新的主伺服器。
這個是一個比較詳細的構架圖，我們在主伺服器上會綁定一個cname，然後應用程序通過cname在主伺服器上進行寫操作。從伺服器會根據不同的應用程序種類劃分到不同的資料庫池裡面，從而提供讀的請求。之所以會分成不同的資料庫池，也是因為請求是分優先順序的，而且請求的數量級也不通。以圖裡面的兩個資料庫池為例，一個是frontend-pool，這一類型的SQL語句一般都比較簡短，而且對響應速度要求很高。而第二個cronjob-pool 一般是一些定時任務的語句。這類型的語句一般會比較複雜，而且有時需要花幾秒或者幾十秒才能完成。把不同類型的請求分開可以避免它們之間的互相影響。另外一個優勢是當查詢語句都基本相似的時候，hot data會緩存在innodb_buffer_pool里，這樣減少了直接的磁碟讀取，提高了響應速度。
我們的資料庫池是通過zookeeper來進行管理的。如果一個從伺服器宕機，或者添加新的從伺服器，我們會用內部研發的zooRoster和zooAnimal在MySQL端和應用程序端自動添加和刪除。
我們除了有對應用提供服務的從伺服器，每個集群還有一些特殊的從伺服器。比如用於備份，數據克隆，以及24小時延時的從伺服器。延時的從伺服器是為了更快的進行線上的數據恢復。
自動化案例分析
由於我們有大量的伺服器，但是團隊人數只有個位數，所以基本上所有的系統維護都是通過自動化實現的。我們內部研發的Booking Admin(badmin)軟體，它能實現操作系統和MySQL版本的自動升級。對指定任務進行自動執行，其中包括資料庫的備份與恢復。也能通過監測伺服器和資料庫的狀態對數據池進行自動添加和刪除的操作。
我們有幾百萬個表，每天開發人員都會添加新表或者更改表結構，我們開發了一套系統，開發人員可以在網頁上提交對錶結構修改的語句，然後後台會自動對提交的語句進行檢測，其中包括語法是否正確，以及是否符合公司內部的要求。如果提交的語句有問題，會實時給出修改建議。如果通過檢測，DDL語句會在主伺服器上自動運行。
接下來給大家詳細介紹一下如何進行資料庫的讀寫擴展。
首先介紹一下，我們是如何擴展讀操作。這個相對來說比較簡單，當badmin檢測到伺服器容量不夠，它會自動的往資料庫池裡面添加伺服器。
上圖是這個添加伺服器的具體流程。
badmin 檢測到容量不夠， 自動像ProvisionAPI請求新建伺服器
ProvisionAPI根據集群的類型提供相應的伺服器配置
伺服器系統安裝完成會被設置成needs-setup的狀態，在這個狀態下MySQL和部分系統配置安裝完成。以上幾個過程大概需要十到十五分鐘的時間。
配置完成後接下來進行數據的克隆。一共有三種方式可供選擇
從克隆從伺服器上進行文件的rsync操作
從備份進行恢復
如果需要克隆的伺服器很多，會自動進行Torrent的方式進行
MySQL克隆完成後會進入到installed的狀態，此時MySQL的主從複製已經開始執行，但是會有一定的數據延遲。
在主從庫數據一致後，我們不會直接把伺服器放到線上進行使用，而是通過tcpdump線上同一個資料庫池裡面的SQL語句進行一個warmup的過程。
當innodb_buffer_pool達到一定的百分比，伺服器被設置成live狀態，此時會在資料庫池裡面被激，接收線上請求。
接下來是對寫擴展的介紹，主要通過對資料庫進行表分離來實現。
以上圖為例，對DB1的tableB和tableC進行表分離。
首先搭建一個新的複製鏈DB2
把tableB和tableC複製到DB2上，然後再DB2通過replication filter從DB1上進行主從複製
DB2搭建相應的資料庫池，然後將讀操作從DB1分離到DB2上
DB2 主資料庫的cname是指向在DB1伺服器，所以寫操作還是在DB1上。
修改所有應用程序的資料庫DB2配置，然後等待所有應用程序的rollout。
當所有的tableB和tableC的流量分離到DB2上後，進行寫操作的分離
DB2的cname指向到DB2的主伺服器，此時tableB,tableC的寫操作是宕機的，這個過程大概是5-10秒
在DB2的主伺服器上去掉replication filter,寫分離完成。
高可用性解決方案
我們的高可用解決方式是用的開源軟體orchestrator。https://github.com/github/orchestrator 軟體的原開發者曾經任職於Booking.com，所以很多功能符合我們的需求。
orchestrator是一個對MySQL Replication的拓撲管理和可視化的工具。當有新的mysql節點添加或者刪除時，它會自動對拓撲進行更新，也可以隨時改MySQL在數據鏈里的層級。它提供網頁的界面操作，也可以通過命令行進行操作。它可以自動檢測MySQL的宕機，並且進行自動的恢復。
上圖orchestrator的主界面，裡面包含了所有集群的總信息。其中藍色的數字表示集群的大小，紅色的表示有多少伺服器在這個幾群里目前是無法連接上的，黃色的部分表示有多少現在是有延遲的。
這是一個MySQL Replication集群的界面。Orchestrator自身是沒有Intermediate Master這個概念的。只要伺服器下面拖拽了一個從伺服器，如果這個伺服器宕機了就會進行自動恢復。它會把下面的從伺服器自動的掛載到其他的性能優良的伺服器上。
測試環境的搭建
我們所有的應用程序的測試系統都是搭建在虛擬機上的。每個程序員可以有一套或者多套自己的獨立完整的測試系統。資料庫的測試系統也是搭建在虛擬機上，並且95%的數據都是線上數據，而且每24小時會將線上的數據更新到測試系統中。需要更新的數據量是PB級別。
上圖是我們的一個測試系統構架，左邊是我們的線上環境，右邊是我們的測試環境。
測試環境有4種不同類型的資料庫
snapbox: 和線上連接並實時接收線上的數據更新
master - slave: 每24小時更新一次，開發者可以在這個數據鏈路上進行各種讀寫測試
rdbprod: 實時接收線上數據更新，如果開發者想對線上數據進行讀操作的測試，可以將配置文件切換到rdbprod上。
測試系統的存儲方式用的是ISCSI，所以每次更新的時候master和slave是對snapbox上的iscsi做snapshot。由於測試系統是每24小時更新一次，所以所有的數據改變在系統更新後都會自動刪除。
我們一共有兩套測試系統，這樣做的目的是為了保持測試系統能隨時在線提供服務。每次做snapshot的時候，主從伺服器是不能訪問的，這個過程短則5-10分鐘，長則30-40分鐘。兩套系統會被分成active和passive兩個狀態。主從伺服器的cname一直指向active set。當passive set成果的做完了snapshot的操作，cname會自動切換到passive set上。這樣宕機的過程只有5-10秒的時間。
TAG:老魚筆記 |