隨著新冠病毒疫情的緩解和控制，全球旅游業(yè)逐漸開始重新復(fù)蘇。尤其在一些度假勝地，游客數(shù)量已經(jīng)恢復(fù)到疫情前的水平。
攜程作為全球領(lǐng)先的一站式旅行平臺(tái)，旗下?lián)碛袛y程旅行網(wǎng)、去哪兒網(wǎng)、Skyscanner 等品牌。攜程旅行網(wǎng)向超過 9000 萬會(huì)員提供酒店預(yù)訂、酒店點(diǎn)評(píng)及特價(jià)酒店查詢、機(jī)票預(yù)訂、飛機(jī)票查詢、時(shí)刻表、票價(jià)查詢、航班查詢等服務(wù)。
隨著業(yè)務(wù)量迅速增長，攜程需要更敏捷的技術(shù)架構(gòu)來滿足不斷激增的并發(fā)與數(shù)據(jù)量，一個(gè)穩(wěn)定、可靠，可以隨業(yè)務(wù)增長不斷擴(kuò)展的數(shù)據(jù)庫對(duì)于攜程來說顯得尤其重要。作為海內(nèi)外在線旅游行業(yè)的翹楚，攜程也曾面臨著數(shù)據(jù)庫帶來的技術(shù)挑戰(zhàn)。
攜程創(chuàng)立于 1999 年，最初選擇使用 SQL Server 數(shù)據(jù)庫，在整體數(shù)據(jù)庫技術(shù)棧中占比達(dá)到 99%。 2012 年初，攜程開始逐步關(guān)注開源技術(shù)，尤其是 MySQL，不過該階段 MySQL 使用占比仍然很低，只有 10% 左右。從 2014 至 2019 年，攜程開始加深 MySQL 的應(yīng)用，并因?yàn)闃I(yè)務(wù)形態(tài)發(fā)生了變化，攜程開始從 SQL Server 轉(zhuǎn)型到 MySQL，對(duì) MySQL 進(jìn)行了深入研究，包括內(nèi)核補(bǔ)丁、全自動(dòng)故障診斷等。
原 MySQL 架構(gòu)痛點(diǎn)與挑戰(zhàn)
攜程的應(yīng)用部署在兩個(gè)或多個(gè) IDC 中，數(shù)據(jù)庫也對(duì)等部署在每個(gè) IDC 中。MySQL 部署方式采用 HA節(jié)點(diǎn)，即主備節(jié)點(diǎn)，在同一機(jī)房部署，另一節(jié)點(diǎn)在不同 IDC 部署，這種方式保證了 HA 切換速度和數(shù)據(jù)的容災(zāi)。比如遇到單機(jī)房故障或者整個(gè)機(jī)房宕機(jī)，可以迅速把第二節(jié)點(diǎn)啟動(dòng)起來。攜程在主備切換和第二切換時(shí)做了很多自動(dòng)化工作，但這種架構(gòu)也有明顯缺點(diǎn)，由于應(yīng)用的無狀態(tài)化，數(shù)據(jù)庫的切換會(huì)造成業(yè)務(wù)的短暫中斷，因?yàn)閿?shù)據(jù)庫只有一個(gè)主節(jié)點(diǎn)。
在擴(kuò)展方式方面，攜程沒有采用中間件的方式，而是采用客戶端實(shí)現(xiàn)分片規(guī)則?？蛻舳嗽谏暇€時(shí)會(huì)確定分片規(guī)則，比如 64。再根據(jù) ID 使用取模運(yùn)算定位到某個(gè)分片，這樣可以更方便地進(jìn)行擴(kuò)展。當(dāng)業(yè)務(wù)增加時(shí)實(shí)例數(shù)量從 1 變成 N ，當(dāng)負(fù)載下降時(shí)也可以縮回來。
但是這種擴(kuò)展方式對(duì) DBA 運(yùn)維來說還有一些挑戰(zhàn)，隨著 DBA 越來越多，聚合會(huì)比較困難，業(yè)務(wù)代碼也變得復(fù)雜。
分布式數(shù)據(jù)庫選型
2018 年，隨著攜程業(yè)務(wù)的快速發(fā)展，底層架構(gòu)需要支持彈性擴(kuò)展，特別是在季節(jié)性高峰期(例如春運(yùn)火車票搶票等)。分布式數(shù)據(jù)庫由于具有 DB 級(jí)彈性、快速擴(kuò)展和混合負(fù)載(HTAP)等優(yōu)勢，更適合業(yè)務(wù)的發(fā)展，攜程開始考慮引入分布式數(shù)據(jù)庫，并進(jìn)行調(diào)研選型。攜程主要從以下幾個(gè)維度考量分布式數(shù)據(jù)庫：
·性能：平衡性能和成本，選擇通用機(jī)型，不使用高端存儲(chǔ)或機(jī)器，并要求響應(yīng)穩(wěn)定;
·運(yùn)維與社區(qū)：學(xué)習(xí)成本適中，運(yùn)維復(fù)雜度低，產(chǎn)品需開源且社區(qū)活躍;
·成本：一方面，業(yè)務(wù)研發(fā)需要學(xué)習(xí)使用 SQL，特別是 MySQL 協(xié)議;另一方面，運(yùn)維團(tuán)隊(duì)希望產(chǎn)品不要過于復(fù)雜，易于維護(hù);
·擴(kuò)展性：分布式數(shù)據(jù)庫需要具有快速的擴(kuò)展能力，擴(kuò)縮容對(duì)業(yè)務(wù)影響小。
2018 年，攜程開始正式引入 TiDB?？紤]到 TiDB 的架構(gòu)和攜程的 IDC 環(huán)境，攜程將 TiDB 分別部署在三個(gè) IDC 機(jī)房(IDC1、IDC2、IDC3)中，遵循同時(shí)部署的標(biāo)準(zhǔn)。TiKV、TiDB 和 PD 均勻分布在三個(gè) IDC 機(jī)房中，業(yè)務(wù)流量可以本地感知到每個(gè)機(jī)房的 TiDB Server ，在單機(jī)房故障時(shí)可以自動(dòng)重啟到其它機(jī)房。因?yàn)榭蛻舳藢?duì) TiDB 進(jìn)行了探活與感知，單個(gè) TiDB 服務(wù)器故障時(shí)客戶端可以重新定向。
TiDB 在酒店和度假結(jié)算場景的應(yīng)用
在酒店和度假結(jié)算場景應(yīng)用中，攜程原 MySQL 架構(gòu)主要采用分片(sharding)的擴(kuò)展方式，對(duì)于酒店和度假結(jié)算這類業(yè)務(wù)來說，分片會(huì)變得非常困難。最初的方案是把 SQL Server 上的數(shù)據(jù)原封不動(dòng)導(dǎo)入到 MySQL 中，但測試后發(fā)現(xiàn)性能不佳，擴(kuò)展性也受限。如果采用分片方式部署，不論從酒店的維度、供應(yīng)商的維度或者是用戶維度，都很難選擇合適的分片鍵( sharding key)，這種方式也對(duì)業(yè)務(wù)代碼侵入性比較大。因此，攜程最終選擇了 TiDB，將酒店和度假結(jié)算業(yè)務(wù)從 SQL server 遷移到 TiDB 上，總數(shù)據(jù)量規(guī)模達(dá)到 8TB，并受到了開發(fā)人員的一致好評(píng)，滿足了性能和擴(kuò)展性的諸多要求。
TiDB 在海量數(shù)據(jù)場景中的應(yīng)用
攜程的海量數(shù)據(jù)場景涉及到大量數(shù)據(jù)存儲(chǔ)。原架構(gòu)中由于單機(jī)存儲(chǔ)限制，擴(kuò)展必須通過 sharding 方式實(shí)現(xiàn)。但該解決方案對(duì)于一些業(yè)務(wù)而言過于復(fù)雜，例如在 IBU 海外業(yè)務(wù)部數(shù)據(jù)，單表數(shù)據(jù)已經(jīng)超過 300 億。應(yīng)用 TiDB 可以大幅提高查詢性能，實(shí)現(xiàn)大量數(shù)據(jù)的高效存儲(chǔ)。TiDB 的行列混存架構(gòu)( TiFlash 和 MPP 技術(shù))，使得攜程部分查詢性能有了20倍提升;在信息安全源數(shù)據(jù)標(biāo)記數(shù)據(jù)時(shí)，單表數(shù)據(jù)也超過了 60 億行，讀寫的響應(yīng)時(shí)間都達(dá)到毫秒級(jí)，單天聚合查詢秒級(jí)返回。
除了使用 TiDB ，攜程還在使用其存儲(chǔ)層 TiKV。引入 TiKV 是因?yàn)閿y程現(xiàn)在的業(yè)務(wù)有一些簡單的 KV 存儲(chǔ)需求，攜程在使用的產(chǎn)品有 Redis 和 Hbase，但是 Hbase 的性能相比于 Redis 比較差，而 Redis 則存在數(shù)據(jù)不一致的風(fēng)險(xiǎn)，比如網(wǎng)絡(luò)抖動(dòng)、中斷等。攜程有一些業(yè)務(wù)有強(qiáng)一致 KV 需求，例如近期引入的酒店取消政策項(xiàng)目，Redis 雖然能滿足業(yè)務(wù)需求，但沒有強(qiáng)一致性能。綜合考量之后，攜程選擇了 TiKV 解決上述挑戰(zhàn)。TiKV 的部署與 TiDB 類似，也是在三個(gè)機(jī)房分布部署，應(yīng)用可以感知到每個(gè)機(jī)房的 PD，并且 PD 也在三個(gè)機(jī)房分別部署。該架構(gòu)可以確保如果出現(xiàn)機(jī)房級(jí)故障，或是單 PD 故障，運(yùn)維團(tuán)隊(duì)都可以做到平滑切換。
TiDB 在攜程的全球化運(yùn)用
隨著攜程近年來開始走向海外，海外業(yè)務(wù)呈現(xiàn)迅猛增長趨勢。攜程也將國內(nèi)成熟的數(shù)據(jù)庫技術(shù)直接用于海外。目前，TiDB 在攜程的國內(nèi)和海外業(yè)務(wù)是分開部署的，海外應(yīng)用復(fù)用了國內(nèi)的 schema 和代碼，監(jiān)控告警方式也與國內(nèi)保持一致，部署方式也是相同的。
攜程引入 TiDB 并完成了一系列內(nèi)部生態(tài)整合，包括發(fā)布系統(tǒng)(如表結(jié)構(gòu)發(fā)布、索引發(fā)布)、數(shù)據(jù)修改和查詢等。由于 TiDB 和 MySQL 采用了相同的協(xié)議，整合過程相對(duì)簡單平滑：
·TiDB 原生支持 Prometheus + Grafana，提供了豐富的診斷數(shù)據(jù)，可以根據(jù) TiDB 故障診斷手冊快速定位問題。
·由于 Grafana 的數(shù)據(jù)在每個(gè)集群上單獨(dú)分布，攜程通過prometheus 源生remote write轉(zhuǎn)發(fā)性能數(shù)據(jù)到攜程統(tǒng)一監(jiān)控平臺(tái)，以便在監(jiān)控平臺(tái)上進(jìn)行性能告警和大盤監(jiān)控。
目前，攜程已經(jīng)順利完成從 SQL server 到 TiDB 的遷移，穩(wěn)定應(yīng)用于攜程的國內(nèi)、海外各業(yè)務(wù)場景中，借助 TiDB HTAP 能力，攜程大幅提高了查詢性能，實(shí)現(xiàn)海量數(shù)據(jù)的高效存儲(chǔ)。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
