京東618期間，各種促銷活動(dòng)，用戶下單量激增，促銷活動(dòng)所產(chǎn)生的價(jià)格波動(dòng)頻繁，為了保障用戶權(quán)益，拒絕站在價(jià)格的高崗上，京東推出了特色服務(wù)——價(jià)格保護(hù)。當(dāng)促銷活動(dòng)正式開始時(shí)，不少用戶開啟了價(jià)格保護(hù)，在此高并發(fā)情況下，如何保證用戶體驗(yàn)，如何保證系統(tǒng)的穩(wěn)定性、高可用、快速計(jì)算結(jié)果，是本文的重點(diǎn)。

我們將按照下圖進(jìn)行實(shí)踐分享：

高筑墻

對于任何網(wǎng)站，我們的系統(tǒng)都需要做出防護(hù)措施，面對海量流量，保障系統(tǒng)不被沖垮；需要通過一些像限流、降級等技術(shù)，對系統(tǒng)進(jìn)行全方位保護(hù)。

從上圖可以看到，我們針對正常用戶和暴力用戶在不影響用戶體驗(yàn)的前提下，采取降級、限流等措施，以保障系統(tǒng)穩(wěn)定。那么我們是如何做的呢，下面我們分別來說說限流、降級。

1、限流

1.1正常用戶限流

正常用戶訪問時(shí)，超出了系統(tǒng)的承載能力，這時(shí)就需要做限流，防止系統(tǒng)被打垮導(dǎo)致不可用。

通過壓測，得到單臺機(jī)器的最大承載能力，而后在單臺服務(wù)器上通過限流計(jì)數(shù)方式進(jìn)行訪問次數(shù)統(tǒng)計(jì)，設(shè)置在一段時(shí)間內(nèi)只可訪問N次。例如，設(shè)置1w/分鐘，當(dāng)在1分鐘內(nèi)達(dá)到閾值時(shí)，將進(jìn)入降級配置，過了該時(shí)間段后，在第2分鐘時(shí)，又重新進(jìn)行計(jì)數(shù)，以此保證單臺機(jī)器不會超出最大承載能力，后續(xù)每臺服務(wù)器都按照這個(gè)閾值進(jìn)行配置。

1.2 暴力用戶限流

暴力用戶頻繁刷應(yīng)用系統(tǒng)，我們需要在這層做一些防刷，比如清洗惡意流量、做一些黑名單。當(dāng)有惡意流量時(shí)，通過對IP、用戶等限制手段把它拒絕在系統(tǒng)之外，防止這些惡意流量把系統(tǒng)沖垮。

這里通過redis計(jì)數(shù)，按照IP或用戶的維度，進(jìn)行原子加1，限制120/分鐘，防止惡意流量影響到我們的正常用戶訪問量。

2、降級

當(dāng)某個(gè)接口出現(xiàn)問題時(shí)，我們能夠?qū)υ摻涌诮导?，快速將結(jié)果返回，不影響主流程。

那么降級是怎么做的呢？

由于我們分布式集群，應(yīng)用服務(wù)器數(shù)量很多，因此，我們需要將降級開關(guān)集中化管理。這里我們制作了統(tǒng)一的配置開關(guān)組件，通過zookeeper將配置推送到各個(gè)服務(wù)器節(jié)點(diǎn)，同時(shí)在zookeeper及應(yīng)用服務(wù)器上分別會有快照數(shù)據(jù)，保證如果統(tǒng)一配置開關(guān)組件發(fā)生問題，我們應(yīng)用也會讀取本地快照數(shù)據(jù)，不影響應(yīng)用本身。同時(shí)在應(yīng)用重啟的時(shí)候，我們也會通過接口拉取配置中心上的最新快照。

對于降級，我們也需要友好提示，在前端如果降級，我們需要友好提示，或者展示降級頁面，盡量不影響用戶體驗(yàn)。

廣積糧

對于大并發(fā)網(wǎng)站，我們需要進(jìn)行各種數(shù)據(jù)準(zhǔn)備，需要區(qū)分動(dòng)態(tài)資源與靜態(tài)資源，將靜態(tài)資源進(jìn)行緩存，以應(yīng)對瞬時(shí)訪問量。

1、CDN

頁面上的靜態(tài)資源，如js、css、picture、靜態(tài)html等資源，可以提前準(zhǔn)備，放到CDN，當(dāng)頁面請求時(shí)，可將這部分網(wǎng)絡(luò)請求打到CDN網(wǎng)絡(luò)上，減少連接請求，降低應(yīng)用服務(wù)器壓力。

采用CDN時(shí)，我們需要注意，當(dāng)web頁面與js發(fā)生改變，無論是先部署web應(yīng)用，還是先推送js到CDN，都有可能發(fā)生js腳本錯(cuò)誤。因此，我們需要在web頁面上做CDN切換開關(guān)，先將資源訪問切換到web機(jī)器上，待上線驗(yàn)證后沒有問題，再部署CDN，切換靜態(tài)資源訪問到CDN。

2、數(shù)據(jù)緩存

我們在獲取數(shù)據(jù)時(shí)，應(yīng)先做出判斷，哪些地方可以用緩存，哪些地方需要讀數(shù)據(jù)庫。動(dòng)態(tài)資源固定屬性，高頻訪問，則應(yīng)主動(dòng)緩存。例如，訂單下單時(shí)快照，訂單的類型、下單時(shí)間、訂單內(nèi)商品、商品下單價(jià)等，就是固定不變的，我們通過接收訂單下單消息，進(jìn)行數(shù)據(jù)主動(dòng)緩存，以便后續(xù)展示訂單內(nèi)商品價(jià)格、計(jì)算價(jià)保申請時(shí)下單價(jià)及促銷價(jià)做出準(zhǔn)備，而無需實(shí)時(shí)訪問訂單接口，降低了后端接口壓力，也加快了獲取速度。

化繁從簡

在高并發(fā)情況下，需要快速響應(yīng)，當(dāng)請求過程中，獲取過多的數(shù)據(jù)，則有可能會降低響應(yīng)速度，因此要將處理簡單化，只做黃金流程即可。

1、前端從簡

用戶訪問頁面時(shí)，只關(guān)心關(guān)鍵部分?jǐn)?shù)據(jù)，因此我們需要優(yōu)先獲取主要數(shù)據(jù)，立刻返回頁面，由頁面通過ajax加載分支數(shù)據(jù)，達(dá)到頁面完整性。這樣既保證了用戶體驗(yàn)，又提升系統(tǒng)的響應(yīng)能力。

圖-價(jià)保申請

以價(jià)保申請頁面為例，用戶進(jìn)入頁面，就是要進(jìn)行商品價(jià)格保護(hù)，因此商品列表、申請按鈕，是用戶最想看見的。其他的信息，如商品最近一次價(jià)保記錄、下單價(jià)格等數(shù)據(jù)，就可以后續(xù)再進(jìn)行加載。

2、后端從簡

用戶進(jìn)行價(jià)格保護(hù)申請時(shí)，由于處理邏輯非常復(fù)雜，需要和20多個(gè)系統(tǒng)進(jìn)行交互，才能計(jì)算出結(jié)果，因此我們采用異步處理方案。那么在接入申請時(shí)，任何系統(tǒng)都可以用三步方式接入申請：

• 插入防重

• 保存申請數(shù)據(jù)

• 下發(fā)處理任務(wù)

這樣保證了用戶申請可快速接入，提升系統(tǒng)的接單能力，后續(xù)對處理任務(wù)進(jìn)行加速，則可以很快的返回結(jié)果，不影響用戶體驗(yàn)。后面的章節(jié)“處理無極限、速戰(zhàn)速決”會具體講解如何最快的處理任務(wù)。

合二為一

在高并發(fā)請求下，由于請求數(shù)巨大，cpu會頻繁切換上下文，導(dǎo)致cpu使用率飄升、性能下降，因此我們要盡量減少請求數(shù)，將可以合并的進(jìn)行合并。

還以上面“圖-價(jià)保申請”為例，由于訂單內(nèi)商品價(jià)格在后端已經(jīng)緩存，我們可以將商品價(jià)格按照訂單的維度進(jìn)行合并，同一個(gè)訂單下所有商品價(jià)格通過一個(gè)ajax進(jìn)行請求訪問。刷新是否符合價(jià)保請求進(jìn)行合并，無論用戶點(diǎn)擊了多少次申請，都以一個(gè)ajax進(jìn)行組合刷新結(jié)果，這樣就減少了請求后端的連接訪問。

分而治之

1、前端網(wǎng)站

我們按照訪問來源、主次流程進(jìn)行集群分散：

目前很多網(wǎng)站都制作了手機(jī)端、PC電腦端，因此按照訪問來源，我們應(yīng)用集群也進(jìn)行區(qū)分。這樣做不但可以使各個(gè)來源集群相互不影響，還能根據(jù)訪問來源不同的訪問量，合理分配機(jī)器。

同時(shí)，我們還按照了主、次業(yè)務(wù)，進(jìn)行了集群區(qū)分，將不重要的業(yè)務(wù)放到非主業(yè)務(wù)集群上，使其不會影響到主業(yè)務(wù)流程。例如“圖-價(jià)保申請”中所示，價(jià)格、最近一次訪問記錄、申請結(jié)果刷新，這3個(gè)功能就不是主業(yè)務(wù)流程，將它們放在非主業(yè)務(wù)集群上進(jìn)行訪問，就算非主業(yè)務(wù)集群出現(xiàn)問題，也不會影響到價(jià)保黃金流程。

2、后端數(shù)據(jù)

后端進(jìn)行讀寫分離，分庫分表：

對數(shù)據(jù)查詢時(shí)，是否需要實(shí)時(shí)數(shù)據(jù)，決定是否采用讀從庫。

對大量數(shù)據(jù)寫時(shí)，應(yīng)將數(shù)據(jù)按照業(yè)務(wù)需要的維度進(jìn)行分庫分表，降低數(shù)據(jù)庫壓力。

這里我們說下我們是如何進(jìn)行分庫的。價(jià)保系統(tǒng)的主要維度是用戶，因此我們按照用戶PIN進(jìn)行分庫路由，以用PIN取Hash值，然后取模。例如我們要分2個(gè)庫，則算法hash值%2。那么問題來了，當(dāng)業(yè)務(wù)量開始增長，2個(gè)庫滿足不了我們的要求，需要擴(kuò)展更多的庫，例如5個(gè)庫，怎么辦？一般做法是將2個(gè)庫的數(shù)據(jù)進(jìn)行清理，然后按照新的庫個(gè)數(shù)5重新打散數(shù)據(jù)，hash值%5。

這樣做實(shí)在太麻煩了，因此我們這里采用二叉樹算法，可以很平滑的擴(kuò)容數(shù)據(jù)庫，不用進(jìn)行數(shù)據(jù)打散重新分配，怎么做的呢？下面我們先回憶下二叉樹：

從上圖可看出，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ù)庫DB-0和DB-1，現(xiàn)在需要擴(kuò)容到8個(gè)數(shù)據(jù)庫，以DB-0為例：

a、我們只需要新找3臺數(shù)據(jù)庫，掛載到DB-0上當(dāng)做從庫，而后進(jìn)行主從復(fù)制；

b、在數(shù)據(jù)量最少的時(shí)間段，將主從復(fù)制切斷，同時(shí)將擴(kuò)容的ABC三個(gè)從庫切換為主庫，此時(shí)4個(gè)數(shù)據(jù)庫數(shù)據(jù)一致，每個(gè)有1/4的數(shù)據(jù)屬于自己，其他數(shù)據(jù)則為冗余數(shù)據(jù)。

c、將路由算法調(diào)整到 hash值%8，部署新應(yīng)用，將所有主庫連接上后進(jìn)行接量，此時(shí)有新、舊2個(gè)應(yīng)用同時(shí)在。但是如果舊應(yīng)用接量，則同步不到新裂變出的數(shù)據(jù)庫2、4、6上；

d、制作數(shù)據(jù)遷移任務(wù)、數(shù)據(jù)比對任務(wù)，將0庫按照切斷主從復(fù)制的時(shí)間開始，按照hash值%8，將2、4、6的數(shù)據(jù)（以最終狀態(tài)為準(zhǔn)）同步到各自的庫上，同時(shí)做數(shù)據(jù)比對驗(yàn)證；

e、停止舊應(yīng)用，由擴(kuò)容后的新應(yīng)用開始承接所有的量，此時(shí)，數(shù)據(jù)庫擴(kuò)容完成。

在擴(kuò)容完成后，我們只需要做冗余數(shù)據(jù)的清理即可，實(shí)現(xiàn)方式很多，例如可以通過數(shù)據(jù)歸檔任務(wù)：

• 寫防重

• 一定時(shí)間段之前的數(shù)據(jù)進(jìn)行歸檔

這樣，經(jīng)過一段時(shí)間后，冗余數(shù)據(jù)就會被清理掉，同時(shí)因?yàn)橛蟹乐?，也不會出現(xiàn)多次歸檔導(dǎo)致歸檔數(shù)據(jù)重復(fù)。

處理無極限

經(jīng)過上面的幾步，用戶可正常的打開頁面，提交商品價(jià)格保護(hù)申請，那么如何能將這巨大的申請量全部吃下，并迅速的返回，成了我們系統(tǒng)的一大難題。處理的慢，就有可能獲取當(dāng)時(shí)促銷價(jià)不準(zhǔn)確，導(dǎo)致用戶價(jià)保失敗，用戶體驗(yàn)會急劇下降。

下面我們將演示如何從有極限到無極限：

圖 – 有極限

大家看，為什么上圖是有極限呢？

從申請入庫到處理申請任務(wù)，都是采用業(yè)務(wù)DB集群，這樣的話，如果接單能力100萬/分鐘，處理能力只有20萬/分鐘，此時(shí)數(shù)據(jù)庫已達(dá)到瓶頸，那么想要處理的更快，只能繼續(xù)做分庫，添加業(yè)務(wù)WK集群機(jī)器，這樣也能讓處理能力上升，但是接單能力這邊就會出現(xiàn)極大的浪費(fèi)。

通過這些，想必大家也能猜到，對，我們將接單、任務(wù)處理2個(gè)集群的DB分開，就能解決這個(gè)問題，同時(shí)相互間也不會有任何影響。怎么做呢？請看下圖：

我們業(yè)務(wù)接單集群，只做業(yè)務(wù)處理，保存到業(yè)務(wù)DB集群，通過業(yè)務(wù)WK集群，將任務(wù)下發(fā)到JMQ中間件，任務(wù)流程處理SV集群進(jìn)行消息監(jiān)聽，將消息分庫插入到流程處理DB中，每個(gè)流程處理DB都會對應(yīng)一套任務(wù)處理WK集群，那么按照上面20萬/分鐘來算，我們這邊只需要5套即可。這樣無論業(yè)務(wù)申請如何大，我們?nèi)蝿?wù)處理都可以隨時(shí)擴(kuò)展。

速戰(zhàn)速決

在上述“處理無極限”中，我們已經(jīng)可以隨時(shí)擴(kuò)展，那么怎么才能最快的任務(wù)處理呢？這節(jié)我們主要說說怎么讓任務(wù)處理速度最快，同時(shí)在出異常的情況下，任務(wù)不丟失。

由于價(jià)保申請?zhí)幚?，業(yè)務(wù)非常復(fù)雜，我們這里采用工作流模式，以任務(wù)節(jié)點(diǎn)程序全自動(dòng)進(jìn)行處理。我們來看下，任務(wù)系統(tǒng)是如何演變，最后達(dá)到速戰(zhàn)速決的。

工作流的流程介紹：通過工作流流程模板Template，一個(gè)申請Apply生成一個(gè)流程實(shí)例Order，每個(gè)流程實(shí)例Order下會有N個(gè)節(jié)點(diǎn)任務(wù)Task。

第一階段

按照Template維度，定時(shí)獲取一定數(shù)量的Task，循環(huán)執(zhí)行。以機(jī)器充分執(zhí)行任務(wù)的角度來看，此時(shí)一臺機(jī)器即可，兩臺機(jī)器執(zhí)行，則有可能抓取到相同的任務(wù)，導(dǎo)致資源浪費(fèi)。

第二階段

數(shù)據(jù)分塊：將一批數(shù)據(jù)，按照預(yù)先設(shè)定好的進(jìn)行分塊，而后可對分塊數(shù)據(jù)進(jìn)行區(qū)分對待。

如上圖，對任務(wù)節(jié)點(diǎn)Task進(jìn)行分塊，此時(shí)定時(shí)獲取Task 維度發(fā)生變化，可從Template、塊2個(gè)維度獲取Task，目前分為2個(gè)塊，則該模板可執(zhí)行機(jī)器為兩臺；塊號越多，則該模板執(zhí)行的機(jī)器越多。

但是我們發(fā)現(xiàn)，最小粒度是Task，為什么要有Template的維度呢？

第三階段

將Template維度去掉，采用Task最小粒度維度，上圖中使用了任務(wù)框架，是我們自主研發(fā)的，如不使用該框架，只要保證最小粒度為Task，一樣可行。

我們將Task以Template+TaskCode生成任務(wù)代碼，再在Task上面進(jìn)行分塊，則達(dá)到了最小粒度：任務(wù)代碼+塊。如上圖所示，還是每個(gè)任務(wù)分2個(gè)塊，此時(shí)3個(gè)任務(wù)2個(gè)塊，一共可以有6臺服務(wù)器進(jìn)行任務(wù)執(zhí)行。此時(shí)速度已經(jīng)很快了，按照最小粒度進(jìn)行區(qū)分，但是還是有機(jī)器的數(shù)量限制，只能加大塊號，以便更多機(jī)器可以執(zhí)行。

第四階段

在生成Task節(jié)點(diǎn)的同時(shí)，將該節(jié)點(diǎn)信息下發(fā)到消息隊(duì)列，通過消息進(jìn)行驅(qū)動(dòng)，從而達(dá)到所有機(jī)器接可執(zhí)行，將速度提升到最快，此時(shí)只要保證任務(wù)內(nèi)部處理夠快即可。

在此階段，當(dāng)任務(wù)執(zhí)行異常、消息丟失，我們還有第三階段的方案進(jìn)行保底、重試，同樣保證任務(wù)可高效執(zhí)行。