京東價(jià)格保護(hù)高并發(fā) | 七步走保證用戶體驗(yàn)
京東618期間，各種促銷活動(dòng)，用戶下單量激增，促銷活動(dòng)所產(chǎn)生的價(jià)格波動(dòng)頻繁，為了保障用戶權(quán)益，拒絕站在價(jià)格的高崗上，京東推出了特色服務(wù)——價(jià)格保護(hù)。當(dāng)促銷活動(dòng)正式開(kāi)始時(shí)，不少用戶開(kāi)啟了價(jià)格保護(hù)，在此高并發(fā)情況下，如何保證用戶體驗(yàn)，如何保證系統(tǒng)的穩(wěn)定性、高可用、快速計(jì)算結(jié)果，是本文的重點(diǎn)。
我們將按照下圖進(jìn)行實(shí)踐分享：
一、高筑墻
對(duì)于任何網(wǎng)站，我們的系統(tǒng)都需要做出防護(hù)措施，面對(duì)海量流量，保障系統(tǒng)不被沖垮;需要通過(guò)一些像限流、降級(jí)等技術(shù)，對(duì)系統(tǒng)進(jìn)行全方位保護(hù)。
從上圖可以看到，我們針對(duì)正常用戶和暴力用戶在不影響用戶體驗(yàn)的前提下，采取降級(jí)、限流等措施，以保障系統(tǒng)穩(wěn)定。那么我們是如何做的呢，下面我們分別來(lái)說(shuō)說(shuō)限流、降級(jí)。
1. 限流
(1) 正常用戶限流
正常用戶訪問(wèn)時(shí)，超出了系統(tǒng)的承載能力，這時(shí)就需要做限流，防止系統(tǒng)被打垮導(dǎo)致不可用。
通過(guò)壓測(cè)，得到單臺(tái)機(jī)器的***承載能力，而后在單臺(tái)服務(wù)器上通過(guò)限流計(jì)數(shù)方式進(jìn)行訪問(wèn)次數(shù)統(tǒng)計(jì)，設(shè)置在一段時(shí)間內(nèi)只可訪問(wèn)N次。例如，設(shè)置1w/分鐘，當(dāng)在1分鐘內(nèi)達(dá)到閾值時(shí)，將進(jìn)入降級(jí)配置，過(guò)了該時(shí)間段后，在第2分鐘時(shí)，又重新進(jìn)行計(jì)數(shù)，以此保證單臺(tái)機(jī)器不會(huì)超出***承載能力，后續(xù)每臺(tái)服務(wù)器都按照這個(gè)閾值進(jìn)行配置。
（2）暴力用戶限流
暴力用戶頻繁刷應(yīng)用系統(tǒng)，我們需要在這層做一些防刷，比如清洗惡意流量、做一些黑名單。當(dāng)有惡意流量時(shí)，通過(guò)對(duì)IP、用戶等限制手段把它拒絕在系統(tǒng)之外，防止這些惡意流量把系統(tǒng)沖垮。
這里通過(guò)redis計(jì)數(shù)，按照IP或用戶的維度，進(jìn)行原子加1，限制120/分鐘，防止惡意流量影響到我們的正常用戶訪問(wèn)量。
2. 降級(jí)
當(dāng)某個(gè)接口出現(xiàn)問(wèn)題時(shí)，我們能夠?qū)υ摻涌诮导?jí)，快速將結(jié)果返回，不影響主流程。
那么降級(jí)是怎么做的呢?
由于我們分布式集群，應(yīng)用服務(wù)器數(shù)量很多，因此，我們需要將降級(jí)開(kāi)關(guān)集中化管理。這里我們制作了統(tǒng)一的配置開(kāi)關(guān)組件，通過(guò)zookeeper將配置推送到各個(gè)服務(wù)器節(jié)點(diǎn)，同時(shí)在zookeeper及應(yīng)用服務(wù)器上分別會(huì)有快照數(shù)據(jù)，保證如果統(tǒng)一配置開(kāi)關(guān)組件發(fā)生問(wèn)題，我們應(yīng)用也會(huì)讀取本地快照數(shù)據(jù)，不影響應(yīng)用本身。同時(shí)在應(yīng)用重啟的時(shí)候，我們也會(huì)通過(guò)接口拉取配置中心上的***快照。
對(duì)于降級(jí)，我們也需要友好提示，在前端如果降級(jí)，我們需要友好提示，或者展示降級(jí)頁(yè)面，盡量不影響用戶體驗(yàn)。
二、廣積糧
對(duì)于大并發(fā)網(wǎng)站，我們需要進(jìn)行各種數(shù)據(jù)準(zhǔn)備，需要區(qū)分動(dòng)態(tài)資源與靜態(tài)資源，將靜態(tài)資源進(jìn)行緩存，以應(yīng)對(duì)瞬時(shí)訪問(wèn)量。
1. CDN
頁(yè)面上的靜態(tài)資源，如js、css、picture、靜態(tài)html等資源，可以提前準(zhǔn)備，放到CDN，當(dāng)頁(yè)面請(qǐng)求時(shí)，可將這部分網(wǎng)絡(luò)請(qǐng)求打到CDN網(wǎng)絡(luò)上，減少連接請(qǐng)求，降低應(yīng)用服務(wù)器壓力。
采用CDN時(shí)，我們需要注意，當(dāng)web頁(yè)面與js發(fā)生改變，無(wú)論是先部署web應(yīng)用，還是先推送js到CDN，都有可能發(fā)生js腳本錯(cuò)誤。因此，我們需要在web頁(yè)面上做CDN切換開(kāi)關(guān)，先將資源訪問(wèn)切換到web機(jī)器上，待上線驗(yàn)證后沒(méi)有問(wèn)題，再部署CDN，切換靜態(tài)資源訪問(wèn)到CDN。
2. 數(shù)據(jù)緩存
我們?cè)讷@取數(shù)據(jù)時(shí)，應(yīng)先做出判斷，哪些地方可以用緩存，哪些地方需要讀數(shù)據(jù)庫(kù)。動(dòng)態(tài)資源固定屬性，高頻訪問(wèn)，則應(yīng)主動(dòng)緩存。例如，訂單下單時(shí)快照，訂單的類型、下單時(shí)間、訂單內(nèi)商品、商品下單價(jià)等，就是固定不變的，我們通過(guò)接收訂單下單消息，進(jìn)行數(shù)據(jù)主動(dòng)緩存，以便后續(xù)展示訂單內(nèi)商品價(jià)格、計(jì)算價(jià)保申請(qǐng)時(shí)下單價(jià)及促銷價(jià)做出準(zhǔn)備，而無(wú)需實(shí)時(shí)訪問(wèn)訂單接口，降低了后端接口壓力，也加快了獲取速度。
三、化繁從簡(jiǎn)
在高并發(fā)情況下，需要快速響應(yīng)，當(dāng)請(qǐng)求過(guò)程中，獲取過(guò)多的數(shù)據(jù)，則有可能會(huì)降低響應(yīng)速度，因此要將處理簡(jiǎn)單化，只做黃金流程即可。
1. 前端從簡(jiǎn)
用戶訪問(wèn)頁(yè)面時(shí)，只關(guān)心關(guān)鍵部分?jǐn)?shù)據(jù)，因此我們需要優(yōu)先獲取主要數(shù)據(jù)，立刻返回頁(yè)面，由頁(yè)面通過(guò)ajax加載分支數(shù)據(jù)，達(dá)到頁(yè)面完整性。這樣既保證了用戶體驗(yàn)，又提升系統(tǒng)的響應(yīng)能力。
圖-價(jià)保申請(qǐng)
以價(jià)保申請(qǐng)頁(yè)面為例，用戶進(jìn)入頁(yè)面，就是要進(jìn)行商品價(jià)格保護(hù)，因此商品列表、申請(qǐng)按鈕，是用戶最想看見(jiàn)的。其他的信息，如商品最近一次價(jià)保記錄、下單價(jià)格等數(shù)據(jù)，就可以后續(xù)再進(jìn)行加載。
2. 后端從簡(jiǎn)
用戶進(jìn)行價(jià)格保護(hù)申請(qǐng)時(shí)，由于處理邏輯非常復(fù)雜，需要和20多個(gè)系統(tǒng)進(jìn)行交互，才能計(jì)算出結(jié)果，因此我們采用異步處理方案。那么在接入申請(qǐng)時(shí)，任何系統(tǒng)都可以用三步方式接入申請(qǐng)：
- 插入防重
- 保存申請(qǐng)數(shù)據(jù)
- 下發(fā)處理任務(wù)
這樣保證了用戶申請(qǐng)可快速接入，提升系統(tǒng)的接單能力，后續(xù)對(duì)處理任務(wù)進(jìn)行加速，則可以很快的返回結(jié)果，不影響用戶體驗(yàn)。后面的章節(jié)“處理無(wú)極限、速戰(zhàn)速?zèng)Q”會(huì)具體講解如何最快的處理任務(wù)。
四、合二為一
在高并發(fā)請(qǐng)求下，由于請(qǐng)求數(shù)巨大，cpu會(huì)頻繁切換上下文，導(dǎo)致cpu使用率飄升、性能下降，因此我們要盡量減少請(qǐng)求數(shù)，將可以合并的進(jìn)行合并。
還以上面“圖-價(jià)保申請(qǐng)”為例，由于訂單內(nèi)商品價(jià)格在后端已經(jīng)緩存，我們可以將商品價(jià)格按照訂單的維度進(jìn)行合并，同一個(gè)訂單下所有商品價(jià)格通過(guò)一個(gè)ajax進(jìn)行請(qǐng)求訪問(wèn)。刷新是否符合價(jià)保請(qǐng)求進(jìn)行合并，無(wú)論用戶點(diǎn)擊了多少次申請(qǐng)，都以一個(gè)ajax進(jìn)行組合刷新結(jié)果，這樣就減少了請(qǐng)求后端的連接訪問(wèn)。
五、分而治之
1. 前端網(wǎng)站
我們按照訪問(wèn)來(lái)源、主次流程進(jìn)行集群分散：
目前很多網(wǎng)站都制作了手機(jī)端、PC電腦端，因此按照訪問(wèn)來(lái)源，我們應(yīng)用集群也進(jìn)行區(qū)分。這樣做不但可以使各個(gè)來(lái)源集群相互不影響，還能根據(jù)訪問(wèn)來(lái)源不同的訪問(wèn)量，合理分配機(jī)器。
同時(shí)，我們還按照了主、次業(yè)務(wù)，進(jìn)行了集群區(qū)分，將不重要的業(yè)務(wù)放到非主業(yè)務(wù)集群上，使其不會(huì)影響到主業(yè)務(wù)流程。例如“圖-價(jià)保申請(qǐng)”中所示，價(jià)格、最近一次訪問(wèn)記錄、申請(qǐng)結(jié)果刷新，這3個(gè)功能就不是主業(yè)務(wù)流程，將它們放在非主業(yè)務(wù)集群上進(jìn)行訪問(wèn)，就算非主業(yè)務(wù)集群出現(xiàn)問(wèn)題，也不會(huì)影響到價(jià)保黃金流程。
2. 后端數(shù)據(jù)
后端進(jìn)行讀寫(xiě)分離，分庫(kù)分表：
對(duì)數(shù)據(jù)查詢時(shí)，是否需要實(shí)時(shí)數(shù)據(jù)，決定是否采用讀從庫(kù)。
對(duì)大量數(shù)據(jù)寫(xiě)時(shí)，應(yīng)將數(shù)據(jù)按照業(yè)務(wù)需要的維度進(jìn)行分庫(kù)分表，降低數(shù)據(jù)庫(kù)壓力。
這里我們說(shuō)下我們是如何進(jìn)行分庫(kù)的。價(jià)保系統(tǒng)的主要維度是用戶，因此我們按照用戶PIN進(jìn)行分庫(kù)路由，以用PIN取Hash值，然后取模。例如我們要分2個(gè)庫(kù)，則算法hash值%2。那么問(wèn)題來(lái)了，當(dāng)業(yè)務(wù)量開(kāi)始增長(zhǎng)，2個(gè)庫(kù)滿足不了我們的要求，需要擴(kuò)展更多的庫(kù)，例如5個(gè)庫(kù)，怎么辦?一般做法是將2個(gè)庫(kù)的數(shù)據(jù)進(jìn)行清理，然后按照新的庫(kù)個(gè)數(shù)5重新打散數(shù)據(jù)，hash值%5。
這樣做實(shí)在太麻煩了，因此我們這里采用二叉樹(shù)算法，可以很平滑的擴(kuò)容數(shù)據(jù)庫(kù)，不用進(jìn)行數(shù)據(jù)打散重新分配，怎么做的呢?下面我們先回憶下二叉樹(shù)：
從上圖可看出，1個(gè)→2個(gè)→4個(gè)→8個(gè)，新裂變出的節(jié)點(diǎn)，只需要將數(shù)據(jù)冗余父節(jié)點(diǎn)，按照2的N次方，向下裂變即可。
那我們看看是如何進(jìn)行擴(kuò)容的：
在擴(kuò)容前，有2個(gè)數(shù)據(jù)庫(kù)DB-0和DB-1，現(xiàn)在需要擴(kuò)容到8個(gè)數(shù)據(jù)庫(kù)，以DB-0為例：
- 我們只需要新找3臺(tái)數(shù)據(jù)庫(kù)，掛載到DB-0上當(dāng)做從庫(kù)，而后進(jìn)行主從復(fù)制;
- 在數(shù)據(jù)量最少的時(shí)間段，將主從復(fù)制切斷，同時(shí)將擴(kuò)容的ABC三個(gè)從庫(kù)切換為主庫(kù)，此時(shí)4個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)一致，每個(gè)有1/4的數(shù)據(jù)屬于自己，其他數(shù)據(jù)則為冗余數(shù)據(jù)。
- 將路由算法調(diào)整到 hash值%8，部署新應(yīng)用，將所有主庫(kù)連接上后進(jìn)行接量，此時(shí)有新、舊2個(gè)應(yīng)用同時(shí)在。但是如果舊應(yīng)用接量，則同步不到新裂變出的數(shù)據(jù)庫(kù)2、4、6上;
- 制作數(shù)據(jù)遷移任務(wù)、數(shù)據(jù)比對(duì)任務(wù)，將0庫(kù)按照切斷主從復(fù)制的時(shí)間開(kāi)始，按照hash值%8，將2、4、6的數(shù)據(jù)(以最終狀態(tài)為準(zhǔn))同步到各自的庫(kù)上，同時(shí)做數(shù)據(jù)比對(duì)驗(yàn)證;
- 停止舊應(yīng)用，由擴(kuò)容后的新應(yīng)用開(kāi)始承接所有的量，此時(shí)，數(shù)據(jù)庫(kù)擴(kuò)容完成。
在擴(kuò)容完成后，我們只需要做冗余數(shù)據(jù)的清理即可，實(shí)現(xiàn)方式很多，例如可以通過(guò)數(shù)據(jù)歸檔任務(wù)：
- 寫(xiě)防重
- 一定時(shí)間段之前的數(shù)據(jù)進(jìn)行歸檔
這樣，經(jīng)過(guò)一段時(shí)間后，冗余數(shù)據(jù)就會(huì)被清理掉，同時(shí)因?yàn)橛蟹乐兀膊粫?huì)出現(xiàn)多次歸檔導(dǎo)致歸檔數(shù)據(jù)重復(fù)。
六、處理無(wú)極限
經(jīng)過(guò)上面的幾步，用戶可正常的打開(kāi)頁(yè)面，提交商品價(jià)格保護(hù)申請(qǐng)，那么如何能將這巨大的申請(qǐng)量全部吃下，并迅速的返回，成了我們系統(tǒng)的一大難題。處理的慢，就有可能獲取當(dāng)時(shí)促銷價(jià)不準(zhǔn)確，導(dǎo)致用戶價(jià)保失敗，用戶體驗(yàn)會(huì)急劇下降。
下面我們將演示如何從有極限到無(wú)極限：
圖 – 有極限
大家看，為什么上圖是有極限呢?
從申請(qǐng)入庫(kù)到處理申請(qǐng)任務(wù)，都是采用業(yè)務(wù)DB集群，這樣的話，如果接單能力100萬(wàn)/分鐘，處理能力只有20萬(wàn)/分鐘，此時(shí)數(shù)據(jù)庫(kù)已達(dá)到瓶頸，那么想要處理的更快，只能繼續(xù)做分庫(kù)，添加業(yè)務(wù)WK集群機(jī)器，這樣也能讓處理能力上升，但是接單能力這邊就會(huì)出現(xiàn)極大的浪費(fèi)。
通過(guò)這些，想必大家也能猜到，對(duì)，我們將接單、任務(wù)處理2個(gè)集群的DB分開(kāi)，就能解決這個(gè)問(wèn)題，同時(shí)相互間也不會(huì)有任何影響。怎么做呢?請(qǐng)看下圖：
我們業(yè)務(wù)接單集群，只做業(yè)務(wù)處理，保存到業(yè)務(wù)DB集群，通過(guò)業(yè)務(wù)WK集群，將任務(wù)下發(fā)到JMQ中間件，任務(wù)流程處理SV集群進(jìn)行消息監(jiān)聽(tīng)，將消息分庫(kù)插入到流程處理DB中，每個(gè)流程處理DB都會(huì)對(duì)應(yīng)一套任務(wù)處理WK集群，那么按照上面20萬(wàn)/分鐘來(lái)算，我們這邊只需要5套即可。這樣無(wú)論業(yè)務(wù)申請(qǐng)如何大，我們?nèi)蝿?wù)處理都可以隨時(shí)擴(kuò)展。
七、速戰(zhàn)速?zèng)Q
在上述“處理無(wú)極限”中，我們已經(jīng)可以隨時(shí)擴(kuò)展，那么怎么才能最快的任務(wù)處理呢?這節(jié)我們主要說(shuō)說(shuō)怎么讓任務(wù)處理速度最快，同時(shí)在出異常的情況下，任務(wù)不丟失。
由于價(jià)保申請(qǐng)?zhí)幚恚瑯I(yè)務(wù)非常復(fù)雜，我們這里采用工作流模式，以任務(wù)節(jié)點(diǎn)程序全自動(dòng)進(jìn)行處理。我們來(lái)看下，任務(wù)系統(tǒng)是如何演變，***達(dá)到速戰(zhàn)速?zèng)Q的。
工作流的流程介紹：通過(guò)工作流流程模板Template，一個(gè)申請(qǐng)Apply生成一個(gè)流程實(shí)例Order，每個(gè)流程實(shí)例Order下會(huì)有N個(gè)節(jié)點(diǎn)任務(wù)Task。
***階段
按照Template維度，定時(shí)獲取一定數(shù)量的Task，循環(huán)執(zhí)行。以機(jī)器充分執(zhí)行任務(wù)的角度來(lái)看，此時(shí)一臺(tái)機(jī)器即可，兩臺(tái)機(jī)器執(zhí)行，則有可能抓取到相同的任務(wù)，導(dǎo)致資源浪費(fèi)。
第二階段
數(shù)據(jù)分塊：將一批數(shù)據(jù)，按照預(yù)先設(shè)定好的進(jìn)行分塊，而后可對(duì)分塊數(shù)據(jù)進(jìn)行區(qū)分對(duì)待。
如上圖，對(duì)任務(wù)節(jié)點(diǎn)Task進(jìn)行分塊，此時(shí)定時(shí)獲取Task 維度發(fā)生變化，可從Template、塊2個(gè)維度獲取Task，目前分為2個(gè)塊，則該模板可執(zhí)行機(jī)器為兩臺(tái);塊號(hào)越多，則該模板執(zhí)行的機(jī)器越多。
但是我們發(fā)現(xiàn)，最小粒度是Task，為什么要有Template的維度呢?
第三階段
將Template維度去掉，采用Task最小粒度維度，上圖中使用了任務(wù)框架，是我們自主研發(fā)的，如不使用該框架，只要保證最小粒度為T(mén)ask，一樣可行。
我們將Task以Template+TaskCode生成任務(wù)代碼，再在Task上面進(jìn)行分塊，則達(dá)到了最小粒度：任務(wù)代碼+塊。如上圖所示，還是每個(gè)任務(wù)分2個(gè)塊，此時(shí)3個(gè)任務(wù)2個(gè)塊，一共可以有6臺(tái)服務(wù)器進(jìn)行任務(wù)執(zhí)行。此時(shí)速度已經(jīng)很快了，按照最小粒度進(jìn)行區(qū)分，但是還是有機(jī)器的數(shù)量限制，只能加大塊號(hào)，以便更多機(jī)器可以執(zhí)行。
第四階段
在生成Task節(jié)點(diǎn)的同時(shí)，將該節(jié)點(diǎn)信息下發(fā)到消息隊(duì)列，通過(guò)消息進(jìn)行驅(qū)動(dòng)，從而達(dá)到所有機(jī)器接可執(zhí)行，將速度提升到最快，此時(shí)只要保證任務(wù)內(nèi)部處理夠快即可。
在此階段，當(dāng)任務(wù)執(zhí)行異常、消息丟失，我們還有第三階段的方案進(jìn)行保底、重試，同樣保證任務(wù)可高效執(zhí)行。
夏慶峰：逆向流程技術(shù)專家，疑難雜癥的終結(jié)者，2014年加入京東，負(fù)責(zé)京東財(cái)務(wù)退款及價(jià)格保護(hù)研發(fā)建設(shè)，擅長(zhǎng)京東逆向流程場(chǎng)景、金額拆分計(jì)算、高并發(fā)下網(wǎng)站優(yōu)化。
【本文來(lái)自51CTO專欄作者張開(kāi)濤的微信公眾號(hào)(開(kāi)濤的博客)，公眾號(hào)id: kaitao-1234567】
