隨著新冠病毒疫情的緩解和控制，全球旅游業(yè)逐漸開始重新復蘇。尤其在一些度假勝地，游客數(shù)量已經(jīng)恢復到疫情前的水平。

攜程作為全球領先的一站式旅行平臺，旗下?lián)碛袛y程旅行網(wǎng)、去哪兒網(wǎng)、Skyscanner 等品牌。攜程旅行網(wǎng)向超過 9000 萬會員提供酒店預訂、酒店點評及特價酒店查詢、機票預訂、飛機票查詢、時刻表、票價查詢、航班查詢等服務。

(資料圖片)

隨著業(yè)務量迅速增長，攜程需要更敏捷的技術架構來滿足不斷激增的并發(fā)與數(shù)據(jù)量，一個穩(wěn)定、可靠，可以隨業(yè)務增長不斷擴展的數(shù)據(jù)庫對于攜程來說顯得尤其重要。作為海內外在線旅游行業(yè)的翹楚，攜程也曾面臨著數(shù)據(jù)庫帶來的技術挑戰(zhàn)。

攜程創(chuàng)立于 1999 年，最初選擇使用 SQL Server 數(shù)據(jù)庫，在整體數(shù)據(jù)庫技術棧中占比達到 99%。 2012 年初，攜程開始逐步關注開源技術，尤其是 MySQL，不過該階段 MySQL 使用占比仍然很低，只有 10% 左右。從 2014 至 2019 年，攜程開始加深 MySQL 的應用，并因為業(yè)務形態(tài)發(fā)生了變化，攜程開始從 SQL Server 轉型到 MySQL，對 MySQL 進行了深入研究，包括內核補丁、全自動故障診斷等。

原 MySQL 架構痛點與挑戰(zhàn)

攜程的應用部署在兩個或多個 IDC 中，數(shù)據(jù)庫也對等部署在每個 IDC 中。MySQL 部署方式采用 HA節(jié)點，即主備節(jié)點，在同一機房部署，另一節(jié)點在不同 IDC 部署，這種方式保證了 HA 切換速度和數(shù)據(jù)的容災。比如遇到單機房故障或者整個機房宕機，可以迅速把第二節(jié)點啟動起來。攜程在主備切換和第二切換時做了很多自動化工作，但這種架構也有明顯缺點，由于應用的無狀態(tài)化，數(shù)據(jù)庫的切換會造成業(yè)務的短暫中斷，因為數(shù)據(jù)庫只有一個主節(jié)點。

在擴展方式方面，攜程沒有采用中間件的方式，而是采用客戶端實現(xiàn)分片規(guī)則。客戶端在上線時會確定分片規(guī)則，比如 64。再根據(jù) ID 使用取模運算定位到某個分片，這樣可以更方便地進行擴展。當業(yè)務增加時實例數(shù)量從 1 變成 N ，當負載下降時也可以縮回來。

但是這種擴展方式對 DBA 運維來說還有一些挑戰(zhàn)，隨著 DBA 越來越多，聚合會比較困難，業(yè)務代碼也變得復雜。

分布式數(shù)據(jù)庫選型

2018 年，隨著攜程業(yè)務的快速發(fā)展，底層架構需要支持彈性擴展，特別是在季節(jié)性高峰期（例如春運火車票搶票等）。分布式數(shù)據(jù)庫由于具有 DB 級彈性、快速擴展和混合負載（HTAP）等優(yōu)勢，更適合業(yè)務的發(fā)展，攜程開始考慮引入分布式數(shù)據(jù)庫，并進行調研選型。攜程主要從以下幾個維度考量分布式數(shù)據(jù)庫：

·性能：平衡性能和成本，選擇通用機型，不使用高端存儲或機器，并要求響應穩(wěn)定；

·運維與社區(qū)：學習成本適中，運維復雜度低，產品需開源且社區(qū)活躍；

·成本：一方面，業(yè)務研發(fā)需要學習使用 SQL，特別是 MySQL 協(xié)議；另一方面，運維團隊希望產品不要過于復雜，易于維護；

·擴展性：分布式數(shù)據(jù)庫需要具有快速的擴展能力，擴縮容對業(yè)務影響小。

2018 年，攜程開始正式引入 TiDB。考慮到 TiDB 的架構和攜程的 IDC 環(huán)境，攜程將 TiDB 分別部署在三個 IDC 機房（IDC1、IDC2、IDC3）中，遵循同時部署的標準。TiKV、TiDB 和 PD 均勻分布在三個 IDC 機房中，業(yè)務流量可以本地感知到每個機房的 TiDB Server ，在單機房故障時可以自動重啟到其它機房。因為客戶端對 TiDB 進行了探活與感知，單個 TiDB 服務器故障時客戶端可以重新定向。

TiDB 在酒店和度假結算場景的應用

在酒店和度假結算場景應用中，攜程原 MySQL 架構主要采用分片（sharding）的擴展方式，對于酒店和度假結算這類業(yè)務來說，分片會變得非常困難。最初的方案是把 SQL Server 上的數(shù)據(jù)原封不動導入到 MySQL 中，但測試后發(fā)現(xiàn)性能不佳，擴展性也受限。如果采用分片方式部署，不論從酒店的維度、供應商的維度或者是用戶維度，都很難選擇合適的分片鍵（ sharding key），這種方式也對業(yè)務代碼侵入性比較大。因此，攜程最終選擇了 TiDB，將酒店和度假結算業(yè)務從 SQL server 遷移到 TiDB 上，總數(shù)據(jù)量規(guī)模達到 8TB，并受到了開發(fā)人員的一致好評，滿足了性能和擴展性的諸多要求。

TiDB 在海量數(shù)據(jù)場景中的應用

攜程的海量數(shù)據(jù)場景涉及到大量數(shù)據(jù)存儲。原架構中由于單機存儲限制，擴展必須通過 sharding 方式實現(xiàn)。但該解決方案對于一些業(yè)務而言過于復雜，例如在 IBU 海外業(yè)務部數(shù)據(jù)，單表數(shù)據(jù)已經(jīng)超過 300 億。應用 TiDB 可以大幅提高查詢性能，實現(xiàn)大量數(shù)據(jù)的高效存儲。TiDB 的行列混存架構（ TiFlash 和 MPP 技術），使得攜程部分查詢性能有了20倍提升；在信息安全源數(shù)據(jù)標記數(shù)據(jù)時，單表數(shù)據(jù)也超過了 60 億行，讀寫的響應時間都達到毫秒級，單天聚合查詢秒級返回。

除了使用 TiDB ，攜程還在使用其存儲層 TiKV。引入 TiKV 是因為攜程現(xiàn)在的業(yè)務有一些簡單的 KV 存儲需求，攜程在使用的產品有 Redis 和 Hbase，但是 Hbase 的性能相比于 Redis 比較差，而 Redis 則存在數(shù)據(jù)不一致的風險，比如網(wǎng)絡抖動、中斷等。攜程有一些業(yè)務有強一致 KV 需求，例如近期引入的酒店取消政策項目，Redis 雖然能滿足業(yè)務需求，但沒有強一致性能。綜合考量之后，攜程選擇了 TiKV 解決上述挑戰(zhàn)。TiKV 的部署與 TiDB 類似，也是在三個機房分布部署，應用可以感知到每個機房的 PD，并且 PD 也在三個機房分別部署。該架構可以確保如果出現(xiàn)機房級故障，或是單 PD 故障，運維團隊都可以做到平滑切換。

TiDB 在攜程的全球化運用

隨著攜程近年來開始走向海外，海外業(yè)務呈現(xiàn)迅猛增長趨勢。攜程也將國內成熟的數(shù)據(jù)庫技術直接用于海外。目前，TiDB 在攜程的國內和海外業(yè)務是分開部署的，海外應用復用了國內的 schema 和代碼，監(jiān)控告警方式也與國內保持一致，部署方式也是相同的。

攜程引入 TiDB 并完成了一系列內部生態(tài)整合，包括發(fā)布系統(tǒng)（如表結構發(fā)布、索引發(fā)布）、數(shù)據(jù)修改和查詢等。由于 TiDB 和 MySQL 采用了相同的協(xié)議，整合過程相對簡單平滑：

·TiDB 原生支持 Prometheus + Grafana，提供了豐富的診斷數(shù)據(jù)，可以根據(jù) TiDB 故障診斷手冊快速定位問題。

·由于 Grafana 的數(shù)據(jù)在每個集群上單獨分布，攜程通過prometheus 源生remote write轉發(fā)性能數(shù)據(jù)到攜程統(tǒng)一監(jiān)控平臺，以便在監(jiān)控平臺上進行性能告警和大盤監(jiān)控。

目前，攜程已經(jīng)順利完成從 SQL server 到 TiDB 的遷移，穩(wěn)定應用于攜程的國內、海外各業(yè)務場景中，借助 TiDB HTAP 能力，攜程大幅提高了查詢性能，實現(xiàn)海量數(shù)據(jù)的高效存儲。

關鍵詞：