隨著新冠病毒疫情的緩解和控制，全球旅遊業逐漸開始重新復甦。尤其在一些度假勝地，遊客數量已經恢復到疫情前的水平。
攜程作為全球領先的一站式旅行平臺，旗下擁有攜程旅行網、去哪兒網、Skyscanner 等品牌。攜程旅行網向超過 9000 萬會員提供酒店預訂、酒店點評及特價酒店查詢、機票預訂、飛機票查詢、時刻表、票價查詢、航班查詢等服務。
隨著業務量迅速增長，攜程需要更敏捷的技術架構來滿足不斷激增的併發與資料量，一個穩定、可靠，可以隨業務增長不斷擴充套件的資料庫對於攜程來說顯得尤其重要。作為海內外線上旅遊行業的翹楚，攜程也曾面臨著資料庫帶來的技術挑戰。
原 MySQL 架構痛點與挑戰
攜程創立於 1999 年，最初選擇使用 SQL Server 資料庫，在整體資料庫技術棧中佔比達到 99%。 2012 年初，攜程開始逐步關注開源技術，尤其是 MySQL，不過該階段 MySQL 使用佔比仍然很低，只有 10% 左右。從 2014 至 2019 年，攜程開始加深 MySQL 的應用，並因為業務形態發生了變化，攜程開始從 SQL Server 轉型到 MySQL，對 MySQL 進行了深入研究，包括核心補丁、全自動故障診斷等。
攜程的應用部署在兩個或多個 IDC 中，資料庫也對等部署在每個 IDC 中。MySQL 部署方式採用 HA節點，即主備節點，在同一機房部署，另一節點在不同 IDC 部署，這種方式保證了 HA 切換速度和資料的容災。比如遇到單機房故障或者整個機房當機，可以迅速把第二節點啟動起來。攜程在主備切換和第二切換時做了很多自動化工作，但這種架構也有明顯缺點，由於應用的無狀態化，資料庫的切換會造成業務的短暫中斷，因為資料庫只有一個主節點。
在擴充套件方式方面，攜程沒有采用中介軟體的方式，而是採用客戶端實現分片規則。客戶端在上線時會確定分片規則，比如 64。再根據 ID 使用取模運算定位到某個分片，這樣可以更方便地進行擴充套件。當業務增加時例項數量從 1 變成 N ，當負載下降時也可以縮回來。
但是這種擴充套件方式對 DBA 運維來說還有一些挑戰，隨著 DBA 越來越多，聚合會比較困難，業務程式碼也變得複雜。
分散式資料庫選型
2018 年，隨著攜程業務的快速發展，底層架構需要支援彈性擴充套件，特別是在季節性高峰期（例如春運火車票搶票等）。分散式資料庫由於具有 DB 級彈性、快速擴充套件和混合負載（HTAP）等優勢，更適合業務的發展，攜程開始考慮引入分散式資料庫，並進行調研選型。攜程主要從以下幾個維度考量分散式資料庫：
- 效能：平衡效能和成本，選擇通用機型，不使用高階儲存或機器，並要求響應穩定；
- 運維與社群：學習成本適中，運維複雜度低，產品需開源且社群活躍；
- 成本：一方面，業務研發需要學習使用 SQL，特別是 MySQL 協議；另一方面，運維團隊希望產品不要過於複雜，易於維護；
- 擴充套件性：分散式資料庫需要具有快速的擴充套件能力，擴縮容對業務影響小。
攜程 TiDB 部署模式
2018 年，攜程開始正式引入 TiDB。考慮到 TiDB 的架構和攜程的 IDC 環境，攜程將 TiDB 分別部署在三個 IDC 機房（IDC1、IDC2、IDC3）中，遵循同時部署的標準。TiKV、TiDB 和 PD 均勻分佈在三個 IDC 機房中，業務流量可以本地感知到每個機房的 TiDB Server ，在單機房故障時可以自動重啟到其它機房。因為客戶端對 TiDB 進行了探活與感知，單個 TiDB 伺服器故障時客戶端可以重新定向。
TiDB 在酒店和度假結算場景的應用
攜程作為一個大型的線上旅遊平臺，其酒店和度假結算場景下需要處理大量的交易資料。攜程原 MySQL 架構主要採用分片（sharding）的擴充套件方式，對於酒店和度假結算這類業務來說，分片會變得非常困難。最初的方案是把 SQL Server 上的資料原封不動匯入到 MySQL 中，但測試後發現效能不佳，擴充套件性也受限。如果採用分片方式部署，不論從酒店的維度、供應商的維度或者是使用者維度，都很難選擇合適的分片鍵（ sharding key），這種方式也對業務程式碼侵入性比較大。
TiDB 的分散式架構可以將資料分散儲存在多個節點上，實現資料的水平擴充套件，提高系統的承載能力。因此，攜程最終選擇了 TiDB，將酒店和度假結算業務從 SQL server 遷移到 TiDB 上，總資料量規模達到 8TB，並受到了開發人員的一致好評，滿足了效能和擴充套件性的諸多要求，同時降低了運維成本，能夠更好地支援攜程業務的發展。
TiDB 在海量資料場景中的應用
攜程的海量資料場景涉及到大量資料儲存。原架構中由於單機儲存限制，擴充套件必須透過 sharding 方式實現。但該解決方案對於一些業務而言過於複雜，例如在 IBU 海外業務部資料，單表資料已經超過 300 億。應用 TiDB 可以大幅提高查詢效能，實現大量資料的高效儲存。TiDB 的行列混存架構（ TiFlash 和 MPP 技術），使得攜程部分查詢效能有了20倍提升；在資訊保安源資料標記資料時，單表資料也超過了 60 億行，讀寫的響應時間都達到毫秒級，單天聚合查詢秒級返回。
除了使用 TiDB ，攜程還在使用其儲存層 TiKV。引入 TiKV 是因為攜程現在的業務有一些簡單的 KV 儲存需求，攜程在使用的產品有 Redis 和 Hbase，但是 Hbase 的效能相比於 Redis 比較差，而 Redis 則存在資料不一致的風險，比如網路抖動、中斷等。攜程有一些業務有強一致 KV 需求，例如近期引入的酒店取消政策專案，Redis 雖然能滿足業務需求，但沒有強一致效能。綜合考量之後，攜程選擇了 TiKV 解決上述挑戰。TiKV 的部署與 TiDB 類似，也是在三個機房分佈部署，應用可以感知到每個機房的 PD，並且 PD 也在三個機房分別部署。該架構可以確保如果出現機房級故障，或是單 PD 故障，運維團隊都可以做到平滑切換。
TiDB 在攜程的全球化運用
隨著攜程近年來開始走向海外，海外業務呈現迅猛增長趨勢。攜程也將國內成熟的資料庫技術直接用於海外。目前，TiDB 在攜程的國內和海外業務是分開部署的，海外應用複用了國內的 schema 和程式碼，監控告警方式也與國內保持一致，部署方式也是相同的。
攜程引入 TiDB 並完成了一系列內部生態整合，包括髮布系統（如表結構釋出、索引發布）、資料修改和查詢等。由於 TiDB 和 MySQL 採用了相同的協議，整合過程相對簡單平滑：
- TiDB 原生支援 Prometheus + Grafana，提供了豐富的診斷資料，可以根據 TiDB 故障診斷手冊快速定位問題。
- 由於 Grafana 的資料在每個叢集上單獨分佈，攜程透過prometheus 源生remote write轉發效能資料到攜程統一監控平臺，以便在監控平臺上進行效能告警和大盤監控。
目前 TiDB 穩定應用於攜程的國內、海外各業務場景中，藉助 TiDB HTAP 能力，攜程大幅提高了查詢效能，實現海量資料的高效儲存。