架構(gòu)

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

大家好，我是冰河~~

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

一、前言

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

二、本章訴求

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

三、應對之道

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

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

接下來，就針對每種應對之道進行詳細的闡述。

四、分離之道

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

4.1 資源分離

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

4.2 接口分離

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

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

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

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

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

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

就秒殺系統(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ù)對時間比較敏感。而像秒殺結(jié)果等與用戶本身相關的一些數(shù)據(jù)，可以稱為靜態(tài)數(shù)據(jù)，因為這些數(shù)據(jù)在整個秒殺活動期間，基本不會發(fā)生變化。

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

4.4 業(yè)務分離

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

4.5 系統(tǒng)分離

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

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

4.6 流量分離

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

五、限流之道

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

5.1 提前預約秒殺

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

5.2 打散客戶端流量

一般秒殺系統(tǒng)的客戶端也會包含：PC、H5、App和小程序，作為秒殺流量的入口，可以在這些入口端設置答題、驗證碼和滑塊等方式將流量打散，因為每個人輸入問答題答案、驗證碼和滑塊的手速不同，就會將瞬時的大并發(fā)流量分散到一小段時間內(nèi)。在秒殺的場景中，不要小看這些處理方式，即使將流量分攤到一秒或者幾百毫秒的時間內(nèi)，也會將流量峰值降低一個甚至幾個量級。

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

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

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

5.3 消息隊列

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

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

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

5.4 網(wǎng)關限流

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

5.5 API限流

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

5.6 應用層限流

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

5.7 安全校驗

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

5.8 活動校驗

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

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

5.9 秒殺品校驗

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

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

5.10 秒殺資格校驗

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

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

5.11 風控校驗

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

5.12 大廠策略

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

六、快速響應之道

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

6.1 多用緩存

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

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

6.2 本地緩存

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

6.3 分布式緩存

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

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

對于提升系統(tǒng)的響應性能來說，光有緩存還不夠，還要在處理的數(shù)據(jù)上要盡量少，不要查詢或者返回無關緊要的數(shù)據(jù)。因為緩存只是提升了IO的執(zhí)行效率，但是除了要提升IO的執(zhí)行效率，還要提升數(shù)據(jù)在網(wǎng)絡中的傳輸效率、以及內(nèi)存和磁盤的讀寫效率。這些都要求我們處理的數(shù)據(jù)要盡量少。

6.5 計算盡量少

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

6.6 流程盡量簡單

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

七、準確一致之道

緩存是秒殺系統(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ù)場景決定是強一致性還是弱一致性，亦或是最終一致性。

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

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

7.3 商品庫存與訂單一致

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

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

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

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

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

8.1 業(yè)務隔離

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

8.2 系統(tǒng)隔離

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

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

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

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

8.4 監(jiān)控數(shù)據(jù)庫與基礎指標

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

8.5 監(jiān)控JVM指標

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

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

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

九、全鏈路壓測之道

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

十、總結(jié)

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