本文轉(zhuǎn)自 | 攜程技術(shù)

作者簡介

Chaplin，攜程資深PMO，平時喜歡解決系統(tǒng)相關(guān)的問題，包括但不限于分布式/大數(shù)據(jù)量/性能/體驗等，不畏復(fù)雜但更喜歡簡單。本文旨在分享攜程機(jī)票后服務(wù)訂單處理團(tuán)隊，在構(gòu)建機(jī)票訂單緩存系統(tǒng)過程中的一些思考總結(jié)，希望能給大家一些啟發(fā)或幫助。通篇分為以下七大部分：背景，瓶頸，選型，架構(gòu)，方案，優(yōu)化，總結(jié)，文章概要如下圖：

一、背景

近些年隨著攜程機(jī)票業(yè)務(wù)的不斷發(fā)展，用戶量和訂單量也穩(wěn)定地增長，再加上用戶訪問入口的多樣性、機(jī)票的有效期特別長等特征，導(dǎo)致查詢流量不斷增長。這些，給基于強(qiáng)依賴訂單數(shù)據(jù)庫的訂單查詢系統(tǒng)帶來了不小的壓力。不僅業(yè)務(wù)上帶來的流量壓力，技術(shù)改造也帶來了更多的流量，如微服務(wù)化的推進(jìn)、機(jī)票前后臺訂單業(yè)務(wù)解耦，不可避免地使得訂單查詢系統(tǒng)被依賴程度進(jìn)一步提高。而且我們沒有使用類似GraphQL 的技術(shù)，之前的前后臺服務(wù)直連數(shù)據(jù)庫，現(xiàn)在使用查詢API，沒有高度定制化產(chǎn)生了數(shù)據(jù)冗余，帶來額外的查詢壓力。作為典型的用戶訂單詳情查詢服務(wù)，承受著越來越重的壓力，峰值時期訂單詳情查詢QPS數(shù)倍于同期訂單TPS。為了保障用戶的使用體驗，支持機(jī)票業(yè)務(wù)的持續(xù)發(fā)展，保證機(jī)票訂單查詢系統(tǒng)的穩(wěn)定高效，構(gòu)建和不斷升級機(jī)票訂單查詢系統(tǒng)，自然成為重要且緊急的事情。

二、瓶頸

大部分應(yīng)用系統(tǒng)的瓶頸都會出在比較慢的地方，如外部資源及磁盤IO或數(shù)據(jù)庫，訂單系統(tǒng)的瓶頸顯而易見，重復(fù)高頻的訂單數(shù)據(jù)訪問，最終帶來的是訂單數(shù)據(jù)庫訪問的壓力。盡管之前通過數(shù)據(jù)庫主從復(fù)制、讀寫分離的手段，一定程度上緩解數(shù)據(jù)庫的壓力。但是從節(jié)點的增加無疑會帶來一些不得不考慮的問題，包括數(shù)據(jù)同步時的AG延遲問題，數(shù)據(jù)庫服務(wù)器的運(yùn)維成本等。不僅局部優(yōu)化有瓶頸，而且我們一直認(rèn)為局部的優(yōu)化，不如總線級別的優(yōu)化來的更有效率，數(shù)據(jù)庫總線跟內(nèi)存總線對于訂單系統(tǒng)數(shù)據(jù)存取速度的提升并不是一個級別。基于以上種種，機(jī)票訂單后處理團(tuán)隊，決定構(gòu)建一套相對完整的基于內(nèi)存數(shù)據(jù)緩存體系，不僅用于緩解機(jī)票訂單數(shù)據(jù)庫的訪問壓力，也用來提高訂單查詢服務(wù)的穩(wěn)定性和容災(zāi)能力。

三、選型

目前各種類型的緩存都活躍在成千上萬的應(yīng)用服務(wù)中，還沒有一種緩存方案可以解決一切的業(yè)務(wù)場景或數(shù)據(jù)類型，我們需要根據(jù)自身的特殊場景和背景，選擇最適合的緩存方案。目前業(yè)內(nèi)用來做緩存的，通常主要有以下幾種：Memcache、Redis，MongoDB。關(guān)于幾者的優(yōu)劣對比網(wǎng)絡(luò)上也有不少的相關(guān)文章，這里不再詳細(xì)列舉。選型并非是一個固定不變的標(biāo)準(zhǔn)，雖然系統(tǒng)設(shè)計沒有銀彈，但是路就在腳下，我們必須要結(jié)合自己的業(yè)務(wù)場景及運(yùn)維能力做出綜合判斷(取舍)，這里說明一下我們關(guān)注的點。(1)故障快速恢復(fù)，機(jī)票訂單的查詢服務(wù)面臨的QPS較高，又是許多上層應(yīng)用服務(wù)的依賴項，由于業(yè)務(wù)比較核心，所以數(shù)據(jù)安全問題必須考慮。因此第一要求故障快速恢復(fù)，攜程的Redis部署是多組多實例多機(jī)柜，完全滿足需求。(2)性能要好，機(jī)票訂單數(shù)據(jù)的查詢，超過92%的場景都是根據(jù)訂單號的查詢，場景比較單一，很少有使用索引條件的緩存查詢需求。單一機(jī)票訂單的數(shù)據(jù)量并不多，所以要求的緩存性能越高，用于查詢集群機(jī)器線程池效率越高，整個查詢集群機(jī)器越少，硬件成本及維護(hù)成本才會變低。(3)輸出穩(wěn)定，緩存性能穩(wěn)定，查詢集群的線程池運(yùn)行越穩(wěn)定，尖刺就會少，整個系統(tǒng)穩(wěn)定性會提高。我們綜合機(jī)票訂單業(yè)務(wù)場景，采用了Redis作為機(jī)票訂單緩存的存儲介質(zhì)。因為Redis的部署特性，要求我們的單個實例不能太大，為了避免實例太大，我們前期做了很多工作，比如容量評估及預(yù)測，通過拆分+壓縮來規(guī)避容量問題。

四、架構(gòu)

在攜程機(jī)票的微服務(wù)化架構(gòu)體系之下，按照業(yè)務(wù)層級的不同，后臺服務(wù)呈現(xiàn)層次化調(diào)用的樹狀結(jié)構(gòu)。比如訂單詳情服務(wù)輸出機(jī)票訂單的狀態(tài)、價格、航班、乘客等各類基本信息，同時依賴于機(jī)票的改簽業(yè)務(wù)、退票業(yè)務(wù)、航變業(yè)務(wù)，支付業(yè)務(wù)等提供的查詢服務(wù)，而這些獨立的子業(yè)務(wù)與訂單詳情服務(wù)本身一樣需要訂單基本信息數(shù)據(jù)作為業(yè)務(wù)支撐。為了避免循環(huán)依賴，需要把訂單基本數(shù)據(jù)查詢業(yè)務(wù)剝離出來，單獨提供底層數(shù)據(jù)訪問服務(wù)，同時支撐不同業(yè)務(wù)模塊。所以機(jī)票訂單后服務(wù)團(tuán)隊依據(jù)服務(wù)的層次設(shè)計了兩級緩存的體系，如下圖所示。(1)一級緩存一級緩存是訂單查詢服務(wù)響應(yīng)結(jié)果級別的緩存。訂單查詢服務(wù)作為一系列核心服務(wù)，支撐了不同前端渠道的訂單查詢請求，包括APP，Online、H5等，同時也支持后臺訂單處理的各個環(huán)節(jié)業(yè)務(wù)對訂單數(shù)據(jù)的查詢需求。訂單查詢服務(wù)的請求QPS很高，對同一個訂單的請求在1秒之內(nèi)有時會達(dá)到十幾次。對于許多業(yè)務(wù)場景來說，1秒的時間內(nèi)訂單的數(shù)據(jù)基本不會發(fā)生變化，因此完全可以將該訂單的整個訂單查詢服務(wù)響應(yīng)結(jié)果緩存起來，設(shè)置秒級別的過期時間。這樣做一方面能夠提高服務(wù)的響應(yīng)速度，另一方面能夠減少對底層數(shù)據(jù)庫服務(wù)的訪問，降低數(shù)據(jù)庫的壓力，預(yù)防意外的或者惡意的流量沖擊。(2)二級緩存二級緩存是針對訂單數(shù)據(jù)庫熱點數(shù)據(jù)表的數(shù)據(jù)的底層緩存。根據(jù)對機(jī)票訂單業(yè)務(wù)的梳理和對數(shù)據(jù)庫數(shù)據(jù)表的訪問頻率的統(tǒng)計，我們篩選出了80+的熱點機(jī)票訂單數(shù)據(jù)表，對每個表的數(shù)據(jù)建立緩存，并提供數(shù)據(jù)查詢服務(wù)接口。這樣一來，將不同業(yè)務(wù)方與訂單數(shù)據(jù)庫解耦，統(tǒng)一的數(shù)據(jù)訪問服務(wù)層更有利于統(tǒng)一建立和管理數(shù)據(jù)緩存系統(tǒng)，提高緩存數(shù)據(jù)的使用效率。同時對底層數(shù)據(jù)庫的垂直拆分和水平拆分，做到數(shù)據(jù)使用的業(yè)務(wù)方無感，提高了系統(tǒng)的擴(kuò)展性。

五、方案

緩存數(shù)據(jù)一致性的實現(xiàn)方案，一般可以分為兩大類：主動式和被動式緩存。主動式緩存就是提前將可能訪問到的數(shù)據(jù)加載到緩存中，然后設(shè)置過期時間，周期性刷新。等到需要查詢數(shù)據(jù)的時候，可以優(yōu)先命中緩存。這種方式比較適合于數(shù)據(jù)量不大，變化不頻繁的場景。被動式緩存是指每次查詢時先從緩存中查詢數(shù)據(jù)，沒有則查詢底層數(shù)據(jù)庫，然后把數(shù)據(jù)庫的查詢結(jié)果加載到緩存，并設(shè)置一定的過期時間。數(shù)據(jù)過期后，當(dāng)再次遇到查詢請求時重復(fù)前面所說的過程。被動式緩存具有延遲加載的特性，也就是只有真正被訪問過的數(shù)據(jù)才會被加載到緩存中，能夠更有效的利用緩存數(shù)據(jù)。機(jī)票訂單的數(shù)據(jù)熱度具有階段性，用戶訂單成交的前后階段訂單查詢頻率較高，用戶的歷史訂單查詢頻率就很低了。因此我們采用被動式加載的方案，隨著時間的推移，老的歷史訂單數(shù)據(jù)會自動逐漸過期，新的訂單數(shù)據(jù)被逐漸加載。緩存數(shù)據(jù)的總量保持平穩(wěn)，同時避免了老舊數(shù)據(jù)的清理。分布式緩存架構(gòu)的數(shù)據(jù)一致性是個難點，這也是訂單處理團(tuán)隊一直在努力思考并解決的重中之重。緩存數(shù)據(jù)意味著數(shù)據(jù)的變更在過期時間之內(nèi)是被忽略的，可能與實際的數(shù)據(jù)庫數(shù)據(jù)有一定差異。一般情況下，一種方案是盡量設(shè)置較短的過期時間，以使緩存數(shù)據(jù)盡快與數(shù)據(jù)源同步。但是較短的過期時間帶來的是緩存命中率的大大降低，削弱了緩存數(shù)據(jù)的效果。為了解決數(shù)據(jù)一致性問題，我們設(shè)計了兩套方案來更新緩存數(shù)據(jù)，保證緩存數(shù)據(jù)的實時性。兩套方案相互補(bǔ)充，避免其一短暫失效而產(chǎn)生一致性問題。方案一的思路是掃描數(shù)據(jù)庫的數(shù)據(jù)變化記錄，比如數(shù)據(jù)表里面的數(shù)據(jù)更新時間戳，或者訂閱數(shù)據(jù)庫的binlog記錄。當(dāng)掃描到數(shù)據(jù)變化時，刪除對應(yīng)的緩存數(shù)據(jù)。方案二的思路是借助于攜程的消息通知平臺服務(wù)。在訂單處理流轉(zhuǎn)的各個重要環(huán)節(jié)，會有消息事件產(chǎn)生。通過訂閱這些消息，能夠感知到訂單數(shù)據(jù)的變化，并且通過對不同消息的影響數(shù)據(jù)范圍可以精準(zhǔn)地配置緩存數(shù)據(jù)更新。兩套方案的并行實施，保證了緩存數(shù)據(jù)的延遲控制在了100毫秒以內(nèi)。緩存的構(gòu)建過程中，我們也遇到幾個必須慎重處理的關(guān)鍵點：緩存穿透、緩存擊穿、緩存雪崩。(1)緩存穿透的解決方案(空標(biāo)記)緩存穿透是指，在數(shù)據(jù)存儲系統(tǒng)中不存在的記錄，不會被存儲到緩存中。這種記錄每次的查詢流量都會穿透到數(shù)據(jù)存儲層。在高流量的場景下，不斷查詢空結(jié)果會大量消耗數(shù)據(jù)查詢服務(wù)的資源，甚至在惡意流量攻擊下可能拖垮數(shù)據(jù)庫系統(tǒng)。以機(jī)票訂單為例，有些訂單購買了保險，也有的訂單沒有購買保險的記錄。沒有保險產(chǎn)品的訂單每次查詢時都會從數(shù)據(jù)庫中查到空的結(jié)果，命中不了緩存，消耗了大量的Batch Request。針對這種情況，我們采取了設(shè)置空標(biāo)記的措施，針對查詢正常返回但是記錄為空的數(shù)據(jù)，將特定的空標(biāo)記寫入緩存，避免了這部分流量穿透到數(shù)據(jù)庫。(2)緩存擊穿的解決方案(分布式鎖)緩存擊穿是指，對于一個熱點KEY，在其失效的瞬時，如果有大量的對這個KEY的請求，都會到達(dá)數(shù)據(jù)庫。我們通過分布式鎖的方式，在緩存數(shù)據(jù)失效的時刻，僅允許單一請求讀取數(shù)據(jù)庫數(shù)據(jù)并加載到緩存。(3)緩存雪崩的解決方案(隨機(jī)時間差)緩存雪崩是指，在同一時間有大量緩存一起失效。我們使用了一個簡單有效的方法，對不同的緩存數(shù)據(jù)設(shè)置過期時間時，采用不同的時間，比如增加一個小的隨機(jī)值。此外，由于不同訂單處理過程中的消息發(fā)生時間不同，而訂單處理過程一般會有等待隊列，處理時間會有差異，也降低了緩存同時失效的風(fēng)險。

六、優(yōu)化

做完以上這些，應(yīng)該算個及格的緩存系統(tǒng)，但是我們相信更優(yōu)秀的系統(tǒng)是通過一步步的迭代及演進(jìn)出來的。機(jī)票訂單緩存系統(tǒng)的優(yōu)化，必然要與機(jī)票訂單的自身特征深度吻合，高度定制化，才能發(fā)揮更加有效的作用。我們通過對攜程機(jī)票訂單以及機(jī)票用戶行為的大量數(shù)據(jù)分析，制定了一些針對性的優(yōu)化措施。(1)全天候分段緩存過期策略(按時間)根據(jù)對機(jī)票訂單系統(tǒng)每日實時訂單量數(shù)據(jù)的分析，實時訂單量呈現(xiàn)雙駝峰的形態(tài)，上午9點到11點以及下午1點到4點之間這兩個時間段內(nèi)，訂單量處于峰值狀態(tài)，中午處于相對的低谷。而夜間訂單量為逐漸下降的趨勢，直至凌晨1點到凌晨3點達(dá)到最低點。這與人們的出行作息時間是非常吻合的。在訂單量的峰值時段，數(shù)據(jù)庫訪問壓力比較大，反之低谷時段則壓力較小。對此我們?yōu)橛唵尾樵兎?wù)的一級緩存設(shè)置了分時段的過期時間策略，業(yè)務(wù)高峰時間段緩存時間相對調(diào)整變長，低峰時段調(diào)整變短。每個查詢服務(wù)可以單獨配置這套規(guī)則，隨時動態(tài)調(diào)整。這樣對于數(shù)據(jù)存儲端壓力來說也就是起到了削峰填谷的作用。(2)訂單狀態(tài)分類策略(按業(yè)務(wù))機(jī)票訂單根據(jù)業(yè)務(wù)定義有各種不同的狀態(tài)，表示著訂單處理流轉(zhuǎn)的各個階段。基于對訂單狀態(tài)及其后續(xù)變更行為數(shù)據(jù)的分析，對于已退票或取消的終態(tài)訂單，其訂單數(shù)據(jù)基本不會再發(fā)生變化。這類訂單的緩存過期時間可以設(shè)置的相對較長；對于已過起飛時間的訂單，用戶再查看訪問訂單數(shù)據(jù)的概率也大大降低，其訂單數(shù)據(jù)緩存時間也可以相對長一些；而訂單處理中未出票等過程態(tài)訂單，短時間狀態(tài)變更的可能性很高，因此不應(yīng)該放入緩存之中。(3)用戶行為的訂單訪問預(yù)測(預(yù)加載)根據(jù)統(tǒng)計，用戶乘機(jī)前的幾個小時內(nèi)，出于關(guān)注出發(fā)時間、機(jī)場航站樓、航班變動，辦理登機(jī)手續(xù)等需要，會頻繁查看訂單數(shù)據(jù)。數(shù)據(jù)訪問的壓力集中在了白天的峰值時間段內(nèi)。基于這種對用戶行為的預(yù)測，我們考慮了在前一天的凌晨業(yè)務(wù)低峰階段，將第二天業(yè)務(wù)高峰時間段內(nèi)起飛的訂單數(shù)據(jù)，提前加載到緩存中預(yù)熱，將高峰時間段的一部分緩存構(gòu)建壓力，轉(zhuǎn)移到了低峰時間段，既提高了低峰時間段的系統(tǒng)資源利用，也緩解了高峰時間段數(shù)據(jù)庫的壓力。不僅如此，更大的好處是，第二天訂單數(shù)據(jù)庫即使有短暫的故障，用戶查詢當(dāng)天出行訂單也不會受到影響，因為數(shù)據(jù)都已經(jīng)提前構(gòu)建在緩存里了。

七、總結(jié)

經(jīng)過查詢系統(tǒng)的不斷迭代，埋點數(shù)據(jù)的統(tǒng)計顯示，訂單緩存數(shù)據(jù)的命中率達(dá)到了90%以上，也就是說對數(shù)據(jù)庫的訪問壓力降低到了原來的十分之一的水平。從數(shù)據(jù)庫層面的性能統(tǒng)計監(jiān)控來看，數(shù)據(jù)庫服務(wù)器的cpu利用率峰值由60%降低到了15%，均值由20%以上降低到了10%以下。對數(shù)據(jù)系統(tǒng)的可用性來說改善效果非常顯著。在服務(wù)響應(yīng)性能方面，緩存系統(tǒng)的建立也帶來了性能的提升。以訂單詳情服務(wù)為例，服務(wù)響應(yīng)時間(PT99)均值由150ms降低到了120ms以下。以下列舉一些保證性能及可靠性的具體技術(shù)點：1)采用了Redis Pipeline技術(shù)，節(jié)省了建立鏈接的時間。2)采用了GZIP壓縮技術(shù)，節(jié)省4-5倍的Redis存儲空間。3)采用了NIO技術(shù)，讓我們的緩存服務(wù)支撐更多的鏈接。4)采用了Hystrix熔斷技術(shù)，保證了單個Redis實例異常時候，可以放棄該實例，保證其他正常讀取，保證高可用。整個緩存系統(tǒng)的構(gòu)建，沒有侵入到復(fù)雜的機(jī)票業(yè)務(wù)中，更像一個“外掛”系統(tǒng)，工作量及業(yè)務(wù)風(fēng)險可控。除緩存系統(tǒng)外，未來的訂單查詢業(yè)務(wù)核心挑戰(zhàn)依然是穩(wěn)定性，包括故障的快速定位，調(diào)用鏈的梳理及簡化。中國程序員VS美國程序員，這也太形象了吧...研究主攻數(shù)據(jù)庫和磁盤故障優(yōu)化，曾經(jīng)復(fù)讀才考上三本，他如今讓華為開出201萬年薪DBA林工：OracleDG 環(huán)境主備業(yè)務(wù)數(shù)據(jù)不同步備庫報 ORA-600 錯誤怎么整？那個從深圳流水線去了紐約做程序員的女工，最近失業(yè)了乘風(fēng)破浪的中國數(shù)據(jù)庫有個程序員老公有多爽？？？做一個國產(chǎn)操作系統(tǒng)，有多難？MySQL 的這個 BUG，坑了多少人？為什么不建議把數(shù)據(jù)庫部署在docker容器內(nèi)？A里正在拆中臺，你還在建中臺嗎？騰訊技術(shù)專家：解密小程序云開發(fā)數(shù)據(jù)庫 | 干貨微服務(wù)架構(gòu)框架？這里為你匯總了15種阿里P8稅后收入170萬？P8、P9 及以上到底是什么水平？機(jī)房生存指南交易、賬務(wù)系統(tǒng)去 Oracle 經(jīng)驗誤執(zhí)行了 rm -rf /*刪庫之后，除了跑路還能怎么整？！DTCC中國數(shù)據(jù)庫技術(shù)大會2020-2019SACC2019中國系統(tǒng)架構(gòu)師大會PostgreSQL 2019中國技術(shù)大會點擊上方文字可以直接進(jìn)入小程序瀏覽，下載請在后臺分別回復(fù)關(guān)鍵詞??DTCC、SACC、PG19即可直接收到完整版 PPT 下載鏈接你「在看」嗎？

總結(jié)

以上是生活随笔為你收集整理的订单失效怎么做的_此招一出，数据库压力降低90%，携程机票订单缓存系统实践...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。