歐洲最大MySQL使用者Booking.com資料庫構架探祕！

吳鑫 Booking.com資料庫工程師Team Lead

2015年加入總部位於阿姆斯特丹的Booking.com資料團隊，現任資料庫工程師團隊負責人，主要是負責Booking.com裡MySQL相關的運營和研發。具有超過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秒的時間。