摘要：對此，公司內(nèi)部決定將票務(wù)訂單庫進行分片來降低單庫壓力，應(yīng)對即將到來的國慶高峰訂單爆發(fā)。從將數(shù)據(jù)實時同步到來確保數(shù)據(jù)的一致。至本文截稿時，在同程內(nèi)部，目前共有數(shù)套集群，部署服務(wù)器數(shù)量近百臺，總數(shù)據(jù)量數(shù)十。作者瞿鍇，同程網(wǎng)資深。

初次接觸 TiDB，是通過同程網(wǎng)首席架構(gòu)師王曉波先生的分享，當時同程網(wǎng)正在使開發(fā)和數(shù)據(jù)庫全面往開源方向轉(zhuǎn)型，由于業(yè)務(wù)需要，很多在線業(yè)務(wù)數(shù)據(jù)量和訪問量都非常的大，而 MySQL 無法滿足大數(shù)據(jù)量下的復(fù)雜查詢需求，為了使數(shù)據(jù)庫分片對開發(fā)透明，同程自研了 DBrouter 。但分片后的合并、實時匯總統(tǒng)計及全量數(shù)據(jù)的監(jiān)控仍然是困擾我們的一個難點。一直沒有特別好的辦法解決。

2016 年國慶前，同程的票務(wù)項目（微信九宮格中的火車票、機票等票務(wù)業(yè)務(wù)背后是同程在提供）由于流量激增，訂單庫壓力越來越大，同時相關(guān)業(yè)務(wù)需求也在增加，開發(fā)不斷的在訂單庫上新增各種查詢，例如為了及時定位異常而增加的限定各類條件的分鐘級訂單量監(jiān)控（每分鐘執(zhí)行根據(jù)不同的條件進行匯總的訂單量）。這樣的功能越來越多，同時訂單庫總大小數(shù) T 左右。對此，公司內(nèi)部決定將票務(wù)訂單庫進行分片來降低單庫壓力，應(yīng)對即將到來的國慶高峰訂單爆發(fā)。

經(jīng)過評估，發(fā)現(xiàn)公司自研的分片可以滿足絕大多數(shù)的查詢需求，但是部分復(fù)雜條件的查詢將會影響整個分片集群的性能，少量的全片掃描 SQL 經(jīng)常會占用 80% 以上的 IO 資源，導(dǎo)致其他的查詢性能下降。這時，剛好我們的首席架構(gòu)師提議，使用 TiDB 試試，經(jīng)過中間件組和 DBA 組的配合測試，我們嘗試將 TiDB 作為所有數(shù)據(jù)的集合庫提供復(fù)雜查詢，分片集群則提供簡單查詢，同時由于 TiDB 高度兼容 MySQL 的連接協(xié)議，我們基于 PingCAP 提供的數(shù)據(jù)同步工具 Syncer 進行了二次開發(fā)，可以自定義庫名和表名（后來同 TiDB 工程師交流，他們最新的 Wormhole & Syncer 也都已經(jīng)支持了自定義選項），同時新增了同步狀態(tài)監(jiān)控，如 TPS、延遲等，如果出現(xiàn)異常，會通過微信告警。從 MySQL 將數(shù)據(jù)實時同步到 TiDB 來確保數(shù)據(jù)的一致。

確定方案后，我們連夜安排壓測同事和開發(fā)同事協(xié)作，緊急測試，發(fā)現(xiàn)這套分片集群+TiDB 的方案能夠滿足我們的功能和性能方面的需求，于是迅速調(diào)整了該項目的架構(gòu)，我們將數(shù)千個 MySQL 分片匯總到一個 TiDB 集群，保障了 2016 年國慶的高峰平穩(wěn)渡過。當時的流量達到了我們平時流量的 2 倍，然而并沒有出現(xiàn)異常。

該實時同步查詢系統(tǒng)架構(gòu)如下所示：

在該項目實施成功后，我們加深了對于 TiDB 的使用。并根據(jù) PingCAP 的建議和協(xié)助部署了各類監(jiān)控。

同時，為了更好的關(guān)注數(shù)據(jù)庫的情況，第一時間發(fā)現(xiàn)異常，我們將 TiDB 的異常報警接入了公司的監(jiān)控系統(tǒng)和自愈系統(tǒng)。當發(fā)生異常的時候，監(jiān)控系統(tǒng)會第一時間發(fā)現(xiàn)，然后自愈系統(tǒng)會依據(jù)提前制定的愈合邏輯處理對應(yīng)異常，在第一時間恢復(fù)應(yīng)用的可用。

業(yè)務(wù)上線以后，我們很快又遷移了機票業(yè)務(wù)實時同步業(yè)務(wù)到 TiDB。至本文截稿時，在同程內(nèi)部，目前共有數(shù)套 TiDB 集群，部署服務(wù)器數(shù)量近百臺，總數(shù)據(jù)量數(shù)十 TB。其中最大的一個集群 10 多個數(shù)據(jù)節(jié)點，近十 TB 數(shù)據(jù)，數(shù)據(jù)量過百億，支撐了每天過億的訪問，并提供千萬級別的數(shù)據(jù)監(jiān)控服務(wù)，平均 QPS 在 5000，高峰 QPS 過萬。

同時，由于 TiDB 的易用性（高度兼容 MySQL 協(xié)議和標準的 SQL 語法），我們目前已將 TiDB 作為一個很重要的數(shù)據(jù)庫部署方案，在項目啟動時就會考慮是否可以在初期就開始使用。在持續(xù)一年多的使用中，我們與 PingCAP 工程師一直保持著溝通和交流，互相之間也經(jīng)常會進行一些技術(shù)和使用方面的溝通。目前最新版的 TiDB 我們也積極與 PingCAP 一起進行測試和問題反饋，他們也非常及時的給予我們反饋并很快的 fix 掉一些 BUG。

現(xiàn)在公司內(nèi)部越來越多的開發(fā)在聯(lián)系 DBA 咨詢 TiDB 的信息，我們給他們的反饋就是：這是一個高度兼容 MySQL 協(xié)議和語法的數(shù)據(jù)庫，非常簡單易用，基本上看下相關(guān)文檔就可以上手。你們在用的時候就可以當它就是一個 MySQL 來使用，只是它能存放的數(shù)據(jù)量遠遠超過 MySQL。而對于 DBA 來講，這就是一個自帶高可用和可動態(tài)擴容的數(shù)據(jù)庫，對外是個 MySQL，對內(nèi)是個分布式數(shù)據(jù)庫。業(yè)務(wù)側(cè)的開發(fā)人員基本沒有學習成本，DBA 維護起來也和 MySQL 有很多相似點，系統(tǒng)生態(tài)非常好。

可以預(yù)見，隨著項目繼續(xù)以及新項目建設(shè)，TiDB 的實例數(shù)和機器數(shù)又會繼續(xù)以較快的速度增長，目前線上用的版本還不是最新的版本，正在做升級到 1.05 的準備工作。我們預(yù)計 2018 年底，TiDB 的集群數(shù)很快就會有 20 套，機器數(shù)數(shù)百臺，這給開發(fā)和運維都帶來了一定的挑戰(zhàn)。如果我們?nèi)匀话凑漳壳暗姆绞浇ㄔO(shè)和運維 TiDB 集群，可能就要面臨增加相關(guān)人力的處境。我們一直在尋找多 TiDB 集群的便捷管理方案，這時一篇文章引起了我們的注意——《Cloud+TiDB 技術(shù)解讀》。我們迅速和 TiDB 工程師取得聯(lián)系，了解到 TiDB 最新的 DBaaS 方案基于 K8S 來自動管理和調(diào)度多個 TiDB 實例，這和我們目前大量 docker 化業(yè)務(wù)和數(shù)據(jù)庫的戰(zhàn)略方向是一致的。通過 TiDB-Operator 使可以自動化部署和管理 TiDB 及周邊工具，自動化部署這些應(yīng)用以及使后端獲得故障轉(zhuǎn)移能力，這樣可以大大降低運維成本，同時提供豐富的接口方便后續(xù)對其進行擴展。

我們計劃 2018 年開始和 PingCAP 合作嘗試引入 TiDB DBaaS 方案。

另外，我們通過同 PingCAP 工程師的深度交流，了解到了 TiDB 的子項目 TiSpark ，后續(xù)計劃引入 TiSpark 來對數(shù)據(jù)進行實時分析、實時數(shù)倉等工作的嘗試，讓技術(shù)對業(yè)務(wù)產(chǎn)生更大的價值。

作者：瞿鍇，同程網(wǎng)資深 DBA 。