架構(gòu)

• 本章難度：★★★☆☆
• 本章重點(diǎn)：全面闡述建設(shè)秒殺系統(tǒng)挑戰(zhàn)的應(yīng)對之道，知己知彼，方案了然于胸，自然有應(yīng)對之道。經(jīng)過長期秒殺大促的沉淀與總結(jié)，針對秒殺系統(tǒng)存在高并發(fā)大流量的挑戰(zhàn)，冰河沉淀出六種應(yīng)對之道：分離、限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

大家好，我是冰河~~

雖然建設(shè)秒殺系統(tǒng)的過程中存在著諸多的挑戰(zhàn)，但是這些挑戰(zhàn)都是有應(yīng)對之道的，對于整個(gè)過程中遇到的難點(diǎn)和痛點(diǎn)，都是會沉淀出對應(yīng)的解決方案。

一、前言

在前面的文章中，詳細(xì)闡述了建設(shè)秒殺系統(tǒng)的目標(biāo)與存在的挑戰(zhàn)，并且簡單羅列了如何應(yīng)對這些挑戰(zhàn)的方式。本章，就詳細(xì)闡述對秒殺系統(tǒng)存在挑戰(zhàn)的應(yīng)對之道，最終構(gòu)建出兼具高并發(fā)、高性能和高可用的秒殺系統(tǒng)。心中不僅了解建設(shè)秒殺系統(tǒng)存在的挑戰(zhàn)，更清楚的知道這些挑戰(zhàn)的應(yīng)對之道，正所謂：知己知彼，百戰(zhàn)不殆，方案了然于胸，自然有應(yīng)對之法。

二、本章訴求

一般一套成熟并且穩(wěn)定、經(jīng)得起實(shí)際大促場景考驗(yàn)的秒殺系統(tǒng)，都是經(jīng)過不斷迭代、優(yōu)化和演化而來的。對于設(shè)計(jì)和研發(fā)秒殺系統(tǒng)的技術(shù)人員來說，心中一定要清晰的知曉建設(shè)秒殺系統(tǒng)存在的挑戰(zhàn)，以及針對這些挑戰(zhàn)的應(yīng)對之法。

三、應(yīng)對之道

對于秒殺系統(tǒng)，站在技術(shù)人員的角度，相信大家多多少少對秒殺系統(tǒng)有所了解了。既然建設(shè)秒殺系統(tǒng)存在著種種的困難和挑戰(zhàn)，那我們就需要從整體上分析這些挑戰(zhàn)的應(yīng)對之法，而不是在真正開發(fā)秒殺系統(tǒng)時(shí)，再去臨時(shí)想方案，查漏補(bǔ)缺，切忌頭痛醫(yī)頭、腳痛醫(yī)腳。

從總體上說，我們應(yīng)對秒殺系統(tǒng)挑戰(zhàn)時(shí)，心中要有一桿秤，在設(shè)計(jì)秒殺系統(tǒng)時(shí)，一定要做到分離、削峰限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

接下來，就針對每種應(yīng)對之道進(jìn)行詳細(xì)的闡述。

四、分離之道

分離之道中，重點(diǎn)在于一個(gè)“分”字，主要包括：前后端資源分離、接口分離，數(shù)據(jù)分離、業(yè)務(wù)分離、系統(tǒng)分離、流量分離。

4.1 資源分離

資源分離，主要指的是前后端的資源分離。目前，除了一些非常老舊的系統(tǒng)之外，一般在開發(fā)互聯(lián)網(wǎng)項(xiàng)目過程中，都會采用前后端分離的架構(gòu)模式，這也是比較普遍的做法。在秒殺系統(tǒng)中，將前端資源分離出來，部署時(shí)可以直接推送到CDN服務(wù)器，CDN服務(wù)器全國各地都有，用戶在訪問系統(tǒng)時(shí)，可以從就近的CDN服務(wù)器上拉取對應(yīng)的資源，能夠極大的增強(qiáng)系統(tǒng)的性能。

4.2 接口分離

接口分離包含兩個(gè)方面：一個(gè)是秒殺接口與其他接口分離，一個(gè)是高頻訪問接口與低頻訪問接口分離。

對于秒殺系統(tǒng)的接口來說，在設(shè)計(jì)上一定要與其他的接口進(jìn)行分離，不要讓秒殺系統(tǒng)的接口與其他業(yè)務(wù)的接口互相關(guān)聯(lián)引用，避免秒殺系統(tǒng)的瞬時(shí)高并發(fā)流量對其他接口造成影響。

就秒殺系統(tǒng)而言，并不是每個(gè)接口的訪問頻次都一樣，一本情況下，商品詳情頁、結(jié)算頁和秒殺下單接口的訪問頻次要遠(yuǎn)遠(yuǎn)大于支付接口的訪問頻次。在設(shè)計(jì)上一定要將這些接口進(jìn)行區(qū)分隔離，對高頻訪問的接口進(jìn)行單獨(dú)的性能優(yōu)化。

4.3 數(shù)據(jù)分離

數(shù)據(jù)分離也會包含兩個(gè)方面：一個(gè)是秒殺數(shù)據(jù)與其他數(shù)據(jù)分離，一個(gè)是動態(tài)數(shù)據(jù)與靜態(tài)數(shù)據(jù)分離。

一般情況下，秒殺數(shù)據(jù)瞬時(shí)的增長率會遠(yuǎn)遠(yuǎn)大于其他數(shù)據(jù)，在數(shù)據(jù)上進(jìn)行分離，可以對秒殺數(shù)據(jù)的存儲設(shè)施進(jìn)行單獨(dú)的針對性優(yōu)化，不能讓秒殺數(shù)據(jù)對其他數(shù)據(jù)產(chǎn)生影響，在數(shù)據(jù)層面對秒殺系統(tǒng)進(jìn)行專有部署。

就秒殺系統(tǒng)而言，本身也會存在著動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)。動態(tài)數(shù)據(jù)在秒殺期間會容易發(fā)生變更，比如秒殺系統(tǒng)的品類、商品的庫存和上下架的狀態(tài)等，都是的動態(tài)數(shù)據(jù)，這些動態(tài)數(shù)據(jù)對時(shí)間比較敏感。而像秒殺結(jié)果等與用戶本身相關(guān)的一些數(shù)據(jù)，可以稱為靜態(tài)數(shù)據(jù)，因?yàn)檫@些數(shù)據(jù)在整個(gè)秒殺活動期間，基本不會發(fā)生變化。

在設(shè)計(jì)上，需要對這些動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)進(jìn)行分離，因?yàn)閿?shù)據(jù)的更新頻率不同，在優(yōu)化手段和架構(gòu)設(shè)計(jì)上也會存在著差異。對動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)進(jìn)行分離后，也可以將服務(wù)端產(chǎn)生的靜態(tài)數(shù)據(jù)推送到CDN。

4.4 業(yè)務(wù)分離

秒殺業(yè)務(wù)不同于普通的商城業(yè)務(wù)，秒殺業(yè)務(wù)的特點(diǎn)就是流量大、持續(xù)的時(shí)間短，在設(shè)計(jì)秒殺系統(tǒng)時(shí)，需要充分考慮到不同業(yè)務(wù)之間的影響，做到秒殺業(yè)務(wù)與其他業(yè)務(wù)之間的分離。

4.5 系統(tǒng)分離

秒殺系統(tǒng)與其他系統(tǒng)不同，秒殺系統(tǒng)需要承接瞬時(shí)高并發(fā)流量，而其他大部分系統(tǒng)的流量則比較平緩。一旦將秒殺系統(tǒng)和其他業(yè)務(wù)系統(tǒng)部署到一起的話，勢必會對其他業(yè)務(wù)系統(tǒng)造成比較大的影響，所以，需要將秒殺系統(tǒng)與其他業(yè)務(wù)系統(tǒng)進(jìn)行分離處理。

在系統(tǒng)分離層面，一般在大廠的秒殺系統(tǒng)中會將秒殺詳情頁系統(tǒng)、秒殺結(jié)算頁系統(tǒng)、購物車系統(tǒng)和訂單系統(tǒng)進(jìn)行分離，并且會申請單獨(dú)的域名和負(fù)載均衡器等，并且會對相應(yīng)的微服務(wù)集群進(jìn)行分組隔離。

4.6 流量分離

看到這里，相信大家對秒殺系統(tǒng)的印象更加深刻了。沒錯(cuò)，秒殺系統(tǒng)的瞬時(shí)流量是巨大的，如果秒殺系統(tǒng)的流量與其他業(yè)務(wù)系統(tǒng)的流量不加以分離處理，其他系統(tǒng)勢必會由于巨大的瞬時(shí)流量而導(dǎo)致各種連鎖問題，所以，在設(shè)計(jì)上，務(wù)必將秒殺系統(tǒng)與其他業(yè)務(wù)系統(tǒng)的流量進(jìn)行分離。

五、限流之道

限流主要是對流量進(jìn)行限制，對于秒殺這種業(yè)務(wù)場景來說，流量是瞬時(shí)且巨大的，期間流量會在幾秒鐘之內(nèi)爬升到峰值，然后馬上又掉下來，形成巨大的毛刺峰值，對系統(tǒng)費(fèi)資源的消耗也是瞬時(shí)且巨大的，需要對這些流量進(jìn)行限制和管控。通常的應(yīng)對方法主要有：提前預(yù)約秒殺、打散客戶端流量、消息隊(duì)列、網(wǎng)關(guān)限流、API限流、應(yīng)用層限流、安全校驗(yàn)、活動校驗(yàn)，秒殺商品校驗(yàn)、秒殺資格校驗(yàn)、風(fēng)控校驗(yàn)，大廠策略。

5.1 提前預(yù)約秒殺

為秒殺系統(tǒng)設(shè)計(jì)一個(gè)預(yù)約功能，或者單獨(dú)設(shè)計(jì)一個(gè)預(yù)約系統(tǒng)，用戶要想?yún)⑴c秒殺搶購，則需要提前預(yù)約商品的搶購，這樣可以在參與搶購的用戶基數(shù)上進(jìn)行控制，能夠提前鎖定參與秒殺搶購的用戶，而不是整個(gè)平臺中所有的用戶都能參與搶購。這樣可以通過將搶購的用戶訪問控制在預(yù)約人數(shù)之內(nèi)，在一定程度上能夠大大減少秒殺的峰值流量，對秒殺系統(tǒng)起到一定的防護(hù)作用。

5.2 打散客戶端流量

一般秒殺系統(tǒng)的客戶端也會包含：PC、H5、App和小程序，作為秒殺流量的入口，可以在這些入口端設(shè)置答題、驗(yàn)證碼和滑塊等方式將流量打散，因?yàn)槊總€(gè)人輸入問答題答案、驗(yàn)證碼和滑塊的手速不同，就會將瞬時(shí)的大并發(fā)流量分散到一小段時(shí)間內(nèi)。在秒殺的場景中，不要小看這些處理方式，即使將流量分?jǐn)偟揭幻牖蛘邘装俸撩氲臅r(shí)間內(nèi)，也會將流量峰值降低一個(gè)甚至幾個(gè)量級。

例如，在沒有將客戶端瀏覽打散的情況下，流量峰值為100萬QPS，使用答題、驗(yàn)證碼和滑塊的方式將流量打散后，流量峰值可能就會下降到80萬QPS、60萬QPS甚至更低，對秒殺系統(tǒng)能過起到有效的防護(hù)作用。

另外，使用問答題、驗(yàn)證碼和滑塊的方式也能夠快速攔截部分刷單流量、防止機(jī)器作弊，起到一定的防刷作用。

注意：目前像阿里這樣的頭部電商平臺，已經(jīng)不會在客戶端使用問答題、驗(yàn)證碼和滑塊等方式將流量打散，更傾向于采用非公平的策略，使用有損逐級限流和分層過濾的方式來達(dá)到系統(tǒng)限流的目的。

5.3 消息隊(duì)列

使用消息隊(duì)列來削峰填谷，通過消息隊(duì)列可以將同步的請求改造成異步請求，將超過下游系統(tǒng)處理范圍的流量暫時(shí)存入消息隊(duì)列中，下游的系統(tǒng)可以根據(jù)自身處理數(shù)據(jù)的性能來消費(fèi)隊(duì)列中的數(shù)據(jù)。

使用消息隊(duì)列對搶購下單異步化之后，前端不能及時(shí)知曉秒殺的結(jié)果數(shù)據(jù)，需要前端定期查詢秒殺的結(jié)果數(shù)據(jù)反饋給用戶。在使用消息隊(duì)列設(shè)計(jì)異步搶購流程時(shí)，有個(gè)小技巧：就是前面的請求將商品的庫存消耗完之后，在商品庫存的緩存中設(shè)置一個(gè)特殊占位符，讓后續(xù)的請求能夠快速失敗，而不再進(jìn)行后續(xù)的業(yè)務(wù)邏輯處理。

可以使用RocketMQ、Kafka和RabbitMQ等消息中間件來實(shí)現(xiàn)請求的異步化和削峰填空，具體使用哪種消息中間件可以根據(jù)自身業(yè)務(wù)進(jìn)行實(shí)際評估。

5.4 網(wǎng)關(guān)限流

網(wǎng)關(guān)一般是一個(gè)系統(tǒng)的入口，可以在網(wǎng)關(guān)層對流量進(jìn)行限流，對超出當(dāng)前系統(tǒng)流量閾值的請求根據(jù)一定的策略進(jìn)行處理，例如拒絕超出當(dāng)前系統(tǒng)流量閾值的請求，快速返回失敗，也可以將超出閾值的流量緩存起來進(jìn)行排隊(duì)，按照一定的順序消費(fèi)這些請求，會對下游的業(yè)務(wù)系統(tǒng)起到一定的防護(hù)作用。

5.5 API限流

API限流也就是對接口進(jìn)行限流，可以使用Google提供的RateLimiter開源包，實(shí)現(xiàn)對應(yīng)的限流策略，在系統(tǒng)中具體的API代碼里進(jìn)行限流。這種方式可以做到針對特定的API接口進(jìn)行限流。

5.6 應(yīng)用層限流

應(yīng)用層的限流可以通過對線程池的限流來實(shí)現(xiàn)，實(shí)現(xiàn)線程池的限流時(shí)，主要是設(shè)置并發(fā)數(shù)限流，可以通過自定義線程池，配置最大的連接數(shù)，以請求隊(duì)列的長度和拒絕策略等參數(shù)進(jìn)行限流，如果隊(duì)列已滿，并且已經(jīng)達(dá)到最大的線程數(shù)，多余的請求就會根據(jù)具體的拒絕策略進(jìn)行處理，以達(dá)到限流的目的和效果。

5.7 安全校驗(yàn)

安全校驗(yàn)就是要識別出請求的流量哪些是安全流量，哪些是不安全的流量，這里說的不安全的流量指的是友商、黃牛黨或者不懷好意的用戶發(fā)起的刷單流量、CC攻擊等，這種流量對系統(tǒng)是有害的，能夠消耗大量的系統(tǒng)資源，為系統(tǒng)造成比較大的壓力，并且這種方式擠占了正常搶購的通道，對正常參與秒殺活動的用戶是不公平的。

5.8 活動校驗(yàn)

活動校驗(yàn)就是接收到請求時(shí)，對活動數(shù)據(jù)進(jìn)行校驗(yàn)，核對活動是否已經(jīng)結(jié)束、是否下架等等，如果活動已經(jīng)結(jié)束或者已經(jīng)下架，則在緩存中設(shè)置特殊的占位符，對后續(xù)的請求進(jìn)行快速失敗處理，不再進(jìn)行后續(xù)的邏輯處理。

做活動校驗(yàn)的原因是用戶在客戶端看到活動有效，當(dāng)流量達(dá)到服務(wù)端時(shí)，活動可能已經(jīng)結(jié)束或者失效了，所以需要做活動的校驗(yàn)處理。

5.9 秒殺品校驗(yàn)

秒殺品校驗(yàn)就是在接收到請求時(shí)，對當(dāng)前的商品信息進(jìn)行校驗(yàn)，核對當(dāng)前商品是否有效，庫存是否充足等。如果商品不再有效、或者庫存已經(jīng)消耗完畢，則在緩存中設(shè)置特殊的占位符，對后續(xù)的請求進(jìn)行快速失敗處理，不再進(jìn)行后續(xù)的邏輯處理。

做秒殺品校驗(yàn)的原因是用戶在客戶端看到活動有效，當(dāng)流量達(dá)到服務(wù)端時(shí)，秒殺品可能已經(jīng)結(jié)束或者失效了，所以需要做秒殺品的校驗(yàn)處理。

5.10 秒殺資格校驗(yàn)

秒殺資格校驗(yàn)主要是對參與秒殺的用戶的資格進(jìn)行校驗(yàn)，比如設(shè)計(jì)了預(yù)約環(huán)節(jié)時(shí)，只有提前預(yù)約過秒殺搶購的用戶才能參與秒殺。再比如，針對當(dāng)前活動設(shè)置了只能秒殺一次的用戶，如果當(dāng)前用戶存在本次活動的秒殺記錄，就不再允許二次秒殺等等。還有就是如果對秒殺品設(shè)置了只針對某些地區(qū)開放秒殺活動，則需要判斷用戶的所在地是否在開放的地區(qū)，如果不在開放秒殺的地區(qū)，則不允許搶購等等。

另外，在秒殺的資格校驗(yàn)上，可能存在同一個(gè)用戶不斷偽造請求的現(xiàn)象，需要加強(qiáng)用戶唯一身份的校驗(yàn)等邏輯。

5.11 風(fēng)控校驗(yàn)

一個(gè)成熟穩(wěn)定的秒殺系統(tǒng)的背后會接入風(fēng)控系統(tǒng)，對整個(gè)秒殺活動進(jìn)行風(fēng)控處理，風(fēng)控系統(tǒng)的建設(shè)不是一朝一夕就能完成的，建立風(fēng)控的過程也是比較困難的，這需要建立在大量數(shù)據(jù)的基礎(chǔ)之上，不斷的完善用戶的畫像，需要通過復(fù)雜的業(yè)務(wù)場景的考驗(yàn)，不斷的修正風(fēng)控模型。

5.12 大廠策略

像阿里這種頭部互聯(lián)網(wǎng)公司，其秒殺系統(tǒng)處了會使用上述限流之道進(jìn)行系統(tǒng)限流外，其處于兼顧用戶體驗(yàn)和系統(tǒng)資源的考慮，一般不會采用問答題、驗(yàn)證碼或者滑塊的方式來打散客戶端流量，更傾向于采用非公平的策略，使用有損逐級限流和分層過濾的方式來達(dá)到系統(tǒng)限流的目的。

六、快速響應(yīng)之道

秒殺的場景雖然是高并發(fā)、大流量的業(yè)務(wù)場景，但是在秒殺場景中，需要快速響應(yīng)用戶的請求，不能讓用戶出現(xiàn)長時(shí)間等待的情況，這就需要在秒殺系統(tǒng)的設(shè)計(jì)上采用一定的策略。對于快速響應(yīng)來說，可以從多用緩存、本地緩存、分布式緩存、數(shù)據(jù)盡量少、計(jì)算盡量少和流程盡量簡單幾個(gè)方面進(jìn)行設(shè)計(jì)。

6.1 多用緩存

像秒殺這種在高并發(fā)大流量場景下要求極致體驗(yàn)的系統(tǒng)，緩存是必不可少的，無論是對前端資源還是對后端數(shù)據(jù)來說，使用緩存都能夠極大的提升系統(tǒng)的性能。同時(shí)，使用緩存也能夠?qū)ο到y(tǒng)進(jìn)行一定的防護(hù)。

如果系統(tǒng)中沒有使用緩存，或者發(fā)生了緩存穿透或者雪崩，瞬時(shí)的大量請求直接打到數(shù)據(jù)庫，那數(shù)據(jù)庫連接會被瞬間耗盡而導(dǎo)致不可用，進(jìn)而導(dǎo)致嚴(yán)重的連鎖反應(yīng)，整個(gè)系統(tǒng)都會被拖垮，所以，使用緩存是非常重要的。

6.2 本地緩存

在秒殺系統(tǒng)中，為了進(jìn)一步提升系統(tǒng)的性能，會將一部分非常熱點(diǎn)的數(shù)據(jù)緩存在本地的JVM內(nèi)存中，接收到請求后，會先從本地緩存中獲取數(shù)據(jù)，如果本地緩存不存在要獲取的數(shù)據(jù)，就會到分布式緩存中進(jìn)行查詢。

6.3 分布式緩存

除了本地緩存外，分布式緩存也是秒殺系統(tǒng)必不可少的，本地緩存的數(shù)據(jù)有限，只能緩存一部分極度熱點(diǎn)的數(shù)據(jù)，并且這些極度熱點(diǎn)的數(shù)據(jù)開始在本地緩存中也不一定存在，這就需要分布式緩存的存在，如果本地緩存中沒有數(shù)據(jù)，就到分布式緩存查詢，盡最大努力提升系統(tǒng)的性能。

6.4 數(shù)據(jù)盡量少

對于提升系統(tǒng)的響應(yīng)性能來說，光有緩存還不夠，還要在處理的數(shù)據(jù)上要盡量少，不要查詢或者返回?zé)o關(guān)緊要的數(shù)據(jù)。因?yàn)榫彺嬷皇翘嵘薎O的執(zhí)行效率，但是除了要提升IO的執(zhí)行效率，還要提升數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸效率、以及內(nèi)存和磁盤的讀寫效率。這些都要求我們處理的數(shù)據(jù)要盡量少。

6.5 計(jì)算盡量少

除了數(shù)據(jù)盡量少以外，對于數(shù)據(jù)的計(jì)算操作也要盡量少，盡量不涉及復(fù)雜的計(jì)算操作，復(fù)雜的計(jì)算操作會消耗大量的CPU資源，會極大的影響系統(tǒng)的響應(yīng)性能。

6.6 流程盡量簡單

秒殺系統(tǒng)在流程設(shè)計(jì)中要盡量簡單，不要涉及到復(fù)雜的業(yè)務(wù)流程，流程越簡單，處理的業(yè)務(wù)邏輯越少，性能就越高效。

七、準(zhǔn)確一致之道

緩存是秒殺系統(tǒng)必不可少的，但是使用緩存之后，就會出現(xiàn)數(shù)據(jù)一致性的問題，這些數(shù)據(jù)一致性的問題，就是需要考慮和處理的，主要包含：緩存與數(shù)據(jù)庫一致、本地緩存與分布式緩存一致、商品庫存與訂單數(shù)據(jù)一致、前端與后端數(shù)據(jù)一致。

7.1 緩存與數(shù)據(jù)庫一致

使用緩存能夠極大的提升系統(tǒng)的性能，但是使用了緩存之后，需要在確保緩存中的數(shù)據(jù)和數(shù)據(jù)庫中的數(shù)據(jù)是一致的。這種一致性需要根據(jù)場景決定是強(qiáng)一致性還是弱一致性，亦或是最終一致性。

7.2 本地緩存與分布式緩存一致

本地緩存和分布式緩存都能夠提升數(shù)據(jù)的性能，對于極度熱點(diǎn)數(shù)據(jù)來說，最好是存儲在本地緩存中來提升系統(tǒng)的性能，但是這就需要考慮本地緩存與分布式緩存數(shù)據(jù)的一致性問題。

7.3 商品庫存與訂單一致

這里說的商品庫存與訂單一致，指的是商品已經(jīng)消耗的庫存數(shù)量與訂單中的商品數(shù)量一致，不能出現(xiàn)超賣問題，這就需要在秒殺系統(tǒng)的設(shè)計(jì)中，充分考慮到商品庫存的扣減問題。

7.4 前端與后端數(shù)據(jù)一致

前端與后端的數(shù)據(jù)一致，指的是在秒殺過程中盡量做到前端的數(shù)據(jù)與后端的數(shù)據(jù)保持一致，這里說的一致，就不是強(qiáng)一致了，而是最終一致。因?yàn)閰⑴c秒殺的用戶很多，可能會出現(xiàn)某個(gè)用戶在客戶端看到的商品庫存剩余100件，發(fā)起秒殺搶購的請求后，請求發(fā)送到服務(wù)端，服務(wù)端檢測到商品庫存已經(jīng)耗光，就會返回庫存不足或者秒殺已結(jié)束的提示，這種場景就可以歸類為最終一致。

八、穩(wěn)定可靠之道

一個(gè)系統(tǒng)的穩(wěn)定性是重中之重要考慮的問題，一個(gè)秒殺系統(tǒng)必須要具備高度的穩(wěn)定性，要想滿足系統(tǒng)的穩(wěn)定性，可以從隔離策略和監(jiān)控的角度來保證系統(tǒng)的穩(wěn)定性。隔離可以從業(yè)務(wù)隔離、系統(tǒng)隔離和數(shù)據(jù)隔離的角度進(jìn)行考慮，監(jiān)控就可以從監(jiān)控?cái)?shù)據(jù)庫與基礎(chǔ)指標(biāo)、JVM指標(biāo)和中間件等指標(biāo)的角度進(jìn)行考慮。

8.1 業(yè)務(wù)隔離

秒殺系統(tǒng)在業(yè)務(wù)上與其他系統(tǒng)進(jìn)行隔離，對于參與秒殺的商品來說，一般會在秒殺活動開始前，提前進(jìn)行提報(bào)，并且指定詳細(xì)的營銷策劃和方案。對于參與用戶來說，提前預(yù)約，可以提前識別流量和系統(tǒng)的并發(fā)數(shù)，根據(jù)具體情況評估是否需要擴(kuò)容、是否需要降級或者調(diào)整限流策略。

8.2 系統(tǒng)隔離

對于被流量沖擊比較大的核心系統(tǒng)進(jìn)行物理隔離，鏈路末端的系統(tǒng)，經(jīng)過前面的削峰限流之后，流量就比較可控了，可以不做物理隔離，在邏輯上進(jìn)行隔離即可。在大廠中，一般會將秒殺的商詳頁系統(tǒng)、秒殺結(jié)算頁系統(tǒng)、購物車系統(tǒng)和訂單系統(tǒng)單獨(dú)隔離出來。

8.3 數(shù)據(jù)隔離

對于秒殺系統(tǒng)的數(shù)據(jù)服務(wù)，例如Redis集群、MySQL集群等要單獨(dú)隔離部署，做到秒殺數(shù)據(jù)與其他業(yè)務(wù)數(shù)據(jù)的隔離。

除此之外，還要將流量正確的路由到秒殺專有的環(huán)境中。

8.4 監(jiān)控?cái)?shù)據(jù)庫與基礎(chǔ)指標(biāo)

除了通過隔離策略增強(qiáng)系統(tǒng)的穩(wěn)定性之外，還要時(shí)刻關(guān)注系統(tǒng)的風(fēng)險(xiǎn)指標(biāo)，對數(shù)據(jù)庫、CPU使用率、內(nèi)存使用率、負(fù)載、網(wǎng)卡、磁盤、IO、網(wǎng)絡(luò)波動等進(jìn)行監(jiān)控。

8.5 監(jiān)控JVM指標(biāo)

監(jiān)控JVM的指標(biāo)可以包含：Young GC和Full GC的次數(shù)和耗時(shí)，線程池的線程數(shù)和等待隊(duì)列，運(yùn)行中的線程，死鎖的線程，以及JVM的堆棧使用情況等等。

8.6 監(jiān)控中間件指標(biāo)

監(jiān)控中間件的指標(biāo)，一般情況下可以緩存的容量、QPS和RT進(jìn)行監(jiān)控，對于數(shù)據(jù)庫的QPS、容量和連接池進(jìn)行監(jiān)控，對消息中間件的QPS、RT以及消息的堆積情況進(jìn)行監(jiān)控，對整個(gè)交易鏈路的分支系統(tǒng)進(jìn)行監(jiān)控等等。

九、全鏈路壓測之道

對于秒殺這種系統(tǒng)高并發(fā)、大流量的系統(tǒng)來說，單一的測試功能和對交易鏈路上某一部分功能都不能測試出整個(gè)秒殺系統(tǒng)的性能瓶頸點(diǎn)，要知道木桶能不能裝滿水是取決于最短的木板，對于系統(tǒng)來說也是，整體性能也是取決于整個(gè)交易鏈路上性能最低的一環(huán)。所以，需要對秒殺系統(tǒng)進(jìn)行全鏈路壓測。根據(jù)實(shí)際壓測出來的數(shù)據(jù)進(jìn)行針對性的優(yōu)化和調(diào)整。

十、總結(jié)

本章，主要是對秒殺系統(tǒng)高并發(fā)大流量的挑戰(zhàn)給出了應(yīng)對之道，從總體上說，我們應(yīng)對秒殺系統(tǒng)挑戰(zhàn)時(shí)，心中要有一桿秤，在設(shè)計(jì)秒殺系統(tǒng)時(shí)，一定要做到分離、削峰限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。