[[355121]]

在秒殺的場景中，對于系統的要求其實就三個字：快、準、穩。

本文主要內容：

五個架構原則

數據要盡量少

首先是指用戶請求的數據能少就少。請求的數據包括上傳給系統的數據和系統返回給用戶的數據(通常就是網頁)。

請求數要盡量少

用戶請求的頁面返回后，瀏覽器渲染這個頁面還要包含其他的額外請求，比如說，這個頁面依賴的 CSS/JavaScript、圖片，以及 Ajax 請求等等都定義為“額外請求”，這些額外請求應該盡量少。

路徑要盡量短

就是用戶發出請求到返回數據這個過程中，需求經過的中間的節點數。

依賴要盡量少

指的是要完成一次用戶請求必須依賴的系統或者服務，這里的依賴指的是強依賴。

高可用

系統中的單點可以說是系統架構上的一個大忌，因為單點意味著沒有備份，風險不可控，我們設計分布式系統最重要的原則就是“消除單點”，另外一種叫法“高可用”。

架構是一種平衡的藝術，而最好的架構一旦脫離了它所適應的場景，一切都將是空談。我們需要記住的是，這里所說的幾點都只是一個個方向而已，我們應該盡量往這些方向上去努力，但也要考慮平衡其他因素。

如何做動靜分離

何為動靜數據

那到底什么才是動靜分離呢?所謂“動靜分離”，其實就是把用戶請求的數據(如 HTML 頁面)劃分為“動態數據”和“靜態數據”。簡單來說，“動態數據”和“靜態數據”的主要區別就是看頁面中輸出的數據是否和 URL、瀏覽者、時間、地域相關，以及是否含有 Cookie 等私密數據。

很多媒體類的網站，某一篇文章的內容不管是你訪問還是我訪問，它都是一樣的。所以它就是一個典型的靜態數據，但是它是個動態頁面。

我們如果現在訪問淘寶的首頁，每個人看到的頁面可能都是不一樣的，淘寶首頁中包含了很多根據訪問者特征推薦的信息，而這些個性化的數據就可以理解為動態數據了。

怎樣對靜態數據做緩存呢?

第一，你應該把靜態數據緩存到離用戶最近的地方。靜態數據就是那些相對不會變化的數據，因此我們可以把它們緩存起來。緩存到哪里呢?常見的就三種，用戶瀏覽器里、CDN 上或者在服務端的 Cache 中。你應該根據情況，把它們盡量緩存到離用戶最近的地方。

第二，靜態化改造就是要直接緩存 HTTP 連接。相較于普通的數據緩存而言，你肯定還聽過系統的靜態化改造。靜態化改造是直接緩存 HTTP 連接而不是僅僅緩存數據，如下圖所示，Web 代理服務器根據請求 URL，直接取出對應的 HTTP 響應頭和響應體然后直接返回，這個響應過程簡單得連 HTTP 協議都不用重新組裝，甚至連 HTTP 請求頭也不需要解析。

第三，讓誰來緩存靜態數據也很重要。不同語言寫的 Cache 軟件處理緩存數據的效率也各不相同。以 Java 為例，因為 Java 系統本身也有其弱點(比如不擅長處理大量連接請求，每個連接消耗的內存較多，Servlet 容器解析 HTTP 協議較慢)，所以你可以不在 Java 層做緩存，而是直接在 Web 服務器層上做，這樣你就可以屏蔽 Java 語言層面的一些弱點;而相比起來，Web 服務器(如 Nginx、Apache、Varnish)也更擅長處理大并發的靜態文件請求。

如何做動靜分離的改造

1. URL 唯一化
2. 分離瀏覽者相關的因素
3. 分離時間因素
4. 異步化地域因素
5. 去掉 Cookie

動靜分離的幾種架構方案

根據架構上的復雜度，有 3 種方案可選：

實體機單機部署:

統一 Cache 層:

加上CDN層:

CDN 化部署方案還有以下幾個特點：

1. 把整個頁面緩存在用戶瀏覽器中;
2. 如果強制刷新整個頁面，也會請求 CDN;
3. 實際有效請求，只是用戶對“刷新搶寶”按鈕的點擊。

秒殺系統熱點數據如何處理?

什么是“熱點”

熱點分為熱點操作和熱點數據。

所謂“熱點操作”，例如大量的刷新頁面、大量的添加購物車、雙十一零點大量的下單等都屬于此類操作。對系統來說，這些操作可以抽象為“讀請求”和“寫請求”，這兩種熱點請求的處理方式大相徑庭，讀請求的優化空間要大一些，而寫請求的瓶頸一般都在存儲層，優化的思路就是根據 CAP 理論做平衡，這個內容我在“減庫存”一文再詳細介紹。

而“熱點數據”比較好理解，那就是用戶的熱點請求對應的數據。而熱點數據又分為“靜態熱點數據”和“動態熱點數據”。

所謂“靜態熱點數據”，就是能夠提前預測的熱點數據。例如，我們可以通過賣家報名的方式提前篩選出來，通過報名系統對這些熱點商品進行打標。另外，我們還可以通過大數據分析來提前發現熱點商品，比如我們分析歷史成交記錄、用戶的購物車記錄，來發現哪些商品可能更熱門、更好賣，這些都是可以提前分析出來的熱點。

所謂“動態熱點數據”，就是不能被提前預測到的，系統在運行過程中臨時產生的熱點。例如，賣家在抖音上做了廣告，然后商品一下就火了，導致它在短時間內被大量購買。

由于熱點操作是用戶的行為，我們不好改變，但能做一些限制和保護，所以本文我主要針對熱點數據來介紹如何進行優化。

發現熱點數據

1. 發現靜態熱點數據
2. 發現動態熱點數據

處理熱點數據

優化

優化熱點數據最有效的辦法就是緩存熱點數據，如果熱點數據做了動靜分離，那么可以長期緩存靜態數據。但是，緩存熱點數據更多的是“臨時”緩存，即不管是靜態數據還是動態數據，都用一個隊列短暫地緩存數秒鐘，由于隊列長度有限，可以采用 LRU 淘汰算法替換。

限制

限制更多的是一種保護機制，限制的辦法也有很多，例如對被訪問商品的 ID 做一致性 Hash，然后根據 Hash 做分桶，每個分桶設置一個處理隊列，這樣可以把熱點商品限制在一個請求隊列里，防止因某些熱點商品占用太多的服務器資源，而使其他請求始終得不到服務器的處理資源。

隔離

秒殺系統設計的第一個原則就是將這種熱點數據隔離出來，不要讓 1% 的請求影響到另外的 99%，隔離出來后也更方便對這 1% 的請求做針對性的優化 。其中隔離又可以分為：業務隔離、系統隔離、數據隔離。

流量削峰怎么做

就像城市里的道路，因為存在早高峰和晚高峰的問題，所以有了錯峰限行的解決方案。

削峰的存在，一是可以讓服務端處理變得更加平穩，二是可以節省服務器的資源成本。

針對秒殺這一場景，削峰從本質上來說就是更多地延緩用戶請求的發出，以便減少和過濾掉一些無效請求，它遵從“請求數要盡量少”的原則。

流量削峰思路

排隊

要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去。

除了消息隊列，類似的排隊方式還有很多，例如：

• 利用線程池加鎖等待也是一種常用的排隊方式;
• 先進先出、先進后出等常用的內存排隊算法的實現方式;
• 把請求序列化到文件中，然后再順序地讀文件(例如基于 MySQL binlog 的同步機制)來恢復請求等方式。

可以看到，這些方式都有一個共同特征，就是把“一步的操作”變成“兩步的操作”，其中增加的一步操作用來起到緩沖的作用。

性能優化

• 減少編碼
• 減少序列化
• Java 極致優化
• 并發讀優化

“減庫存”核心邏輯

這是非常重要的，其他所有步驟都是做一些輔助性的。庫存 100 件就賣 100 件，在數據庫里減到 0 就好了啊，這有什么麻煩的?是的，理論上是這樣，但是具體到業務場景中，“減庫存”就不是這么簡單了。

減庫存有哪幾種方式

在商品頁面點了“立即購買”按鈕，核對信息之后點擊“提交訂單”，這一步稱為下單操作。下單之后，你只有真正完成付款操作才能算真正購買，也就是俗話說的“落袋為安”。

減庫存操作一般有如下幾個方式：

下單減庫存

即當買家下單后，在商品的總庫存中減去買家購買數量。下單減庫存是最簡單的減庫存方式，也是控制最精確的一種，下單時直接通過數據庫的事務機制控制商品庫存，這樣一定不會出現超賣的情況。但是你要知道，有些人下完單可能并不會付款。

付款減庫存

即買家下單后，并不立即減庫存，而是等到有用戶付款后才真正減庫存，否則庫存一直保留給其他買家。但因為付款時才減庫存，如果并發比較高，有可能出現買家下單后付不了款的情況，因為可能商品已經被其他人買走了。

預扣庫存

這種方式相對復雜一些，買家下單后，庫存為其保留一定的時間(如 10 分鐘)，超過這個時間，庫存將會自動釋放，釋放后其他買家就可以繼續購買。在買家付款前，系統會校驗該訂單的庫存是否還有保留：如果沒有保留，則再次嘗試預扣;如果庫存不足(也就是預扣失敗)則不允許繼續付款;如果預扣成功，則完成付款并實際地減去庫存。

高可用建設應該從哪里著手

說到系統的高可用建設，它其實是一個系統工程，需要考慮到系統建設的各個階段，也就是說它其實貫穿了系統建設的整個生命周期，如下圖所示：

架構階段

架構階段主要考慮系統的可擴展性和容錯性，要避免系統出現單點問題。例如多機房單元化部署，即使某個城市的某個機房出現整體故障，仍然不會影響整體網站的運轉。

編碼階段

編碼最重要的是保證代碼的健壯性，例如涉及遠程調用問題時，要設置合理的超時退出機制，防止被其他系統拖垮，也要對調用的返回結果集有預期，防止返回的結果超出程序處理范圍，最常見的做法就是對錯誤異常進行捕獲，對無法預料的錯誤要有默認處理結果。

測試階段

測試主要是保證測試用例的覆蓋度，保證最壞情況發生時，我們也有相應的處理流程。

發布階段

發布時也有一些地方需要注意，因為發布時最容易出現錯誤，因此要有緊急的回滾機制。

運行階段

運行時是系統的常態，系統大部分時間都會處于運行態，運行態最重要的是對系統的監控要準確及時，發現問題能夠準確報警并且報警數據要準確詳細，以便于排查問題。

故障發生

故障發生時首先最重要的就是及時止損，例如由于程序問題導致商品價格錯誤，那就要及時下架商品或者關閉購買鏈接，防止造成重大資產損失。然后就是要能夠及時恢復服務，并定位原因解決問題。

在遇到大流量時，我們應該怎么最大化的保障我們的系統正常運行呢?

降級

所謂“降級”，就是當系統的容量達到一定程度時，限制或者關閉系統的某些非核心功能，從而把有限的資源保留給更核心的業務。它是一個有目的、有計劃的執行過程，所以對降級我們一般需要有一套預案來配合執行。如果我們把它系統化，就可以通過預案系統和開關系統來實現降級。

限流

限流就是當系統容量達到瓶頸時，我們需要通過限制一部分流量來保護系統，并做到既可以人工執行開關，也支持自動化保護的措施。

客戶端限流和服務端限流的優缺點：

客戶端限流，好處可以限制請求的發出，通過減少發出無用請求從而減少對系統的消耗。缺點就是當客戶端比較分散時，沒法設置合理的限流閾值：如果閾值設的太小，會導致服務端沒有達到瓶頸時客戶端已經被限制;而如果設的太大，則起不到限制的作用。

服務端限流，好處是可以根據服務端的性能設置合理的閾值，而缺點就是被限制的請求都是無效的請求，處理這些無效的請求本身也會消耗服務器資源。

常見限流算法

計數器(固定窗口)算法

計數器算法是使用計數器在周期內累加訪問次數，當達到設定的限流值時，觸發限流策略。下一個周期開始時，進行清零，重新計數。

此算法在單機還是分布式環境下實現都非常簡單，使用redis的incr原子自增性和線程安全即可輕松實現。

滑動窗口算法

滑動窗口算法是將時間周期分為N個小周期，分別記錄每個小周期內訪問次數，并且根據時間滑動刪除過期的小周期。此算法可以很好的解決固定窗口算法的臨界問題。

漏桶算法

漏桶算法是訪問請求到達時直接放入漏桶，如當前容量已達到上限(限流值)，則進行丟棄(觸發限流策略)。漏桶以固定的速率進行釋放訪問請求(即請求通過)，直到漏桶為空。

令牌桶算法

令牌桶算法是程序以r(r=時間周期/限流值)的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達時向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發限流策略

拒絕服務

如果限流還不能解決問題，最后一招就是直接拒絕服務了。當系統負載達到一定閾值時，例如 CPU 使用率達到 90% 或者系統 load 值達到 2*CPU 核數時，系統直接拒絕所有請求，這種方式是最暴力但也最有效的系統保護方式。例如秒殺系統，我們在如下幾個環節設計過載保護：

在最前端的 Nginx 上設置過載保護，當機器負載達到某個值時直接拒絕 HTTP 請求并返回 503 錯誤碼，在 Java 層同樣也可以設計過載保護。

拒絕服務可以說是一種不得已的兜底方案，用以防止最壞情況發生，防止因把服務器壓跨而長時間徹底無法提供服務。像這種系統過載保護雖然在過載時無法提供服務，但是系統仍然可以運作，當負載下降時又很容易恢復，所以每個系統和每個環節都應該設置這個兜底方案，對系統做最壞情況下的保護。

緩存問題

緩存雪崩

數據未加載到緩存中，或者緩存同時在大范圍中失效，導致所有請求查找數據庫，導致數據庫、CPU 和內存過載，甚至停機。

一個簡單的雪崩過程：

1) Redis 集群的大面積故障;

2) 緩存失敗，但仍有大量請求訪問緩存服務 Redis;

3) 在大量 Redis 請求失敗后，請求轉向數據庫;

4) 數據庫請求急劇增加，導致數據庫被打死;

5) 由于你應用程序服務大部分都依賴于數據庫和 Redis 服務，它很快就會導致服務器集群的雪崩，最后整個系統將徹底崩潰。

解決辦法：

事前：高可用的緩存

高可用的緩存是防止出現整個緩存故障。即使個別節點，機器甚甚至機房都關閉，系統仍然可以提供服務，Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都可以做到高可用。

事中：緩存降級(臨時支持)

當訪問次數急劇增加導致服務出現問題時，我們如何確保服務仍然可用。在國內使用比較多的是 Hystrix，它通過熔斷、降級、限流三個手段來降低雪崩發生后的損失。只要確保數據庫不死，系統總可以響應請求，每年的春節 12306 我們不都是這么過來的嗎?只要還可以響應起碼還有搶到票的機會。

事后：Redis 備份和快速預熱

1) Redis 數據備份和恢復

2) 快速緩存預熱

緩存擊穿

緩存擊穿意味著當熱點數據存儲到期時，多個線程同時請求熱點數據。因為緩存剛過期，所有并發請求都會到數據庫查詢數據。

解決辦法：

實際上，在大多數實際業務場景中，緩存擊穿是實時發生的，但不會對數據庫造成太大壓力，因為一般的公司業務，并發量不會那么高。當然如果你不幸有這種情況，你可以通過設置這些熱點鍵，使其永遠不會過期。另一種方法是通過互斥鎖來控制查詢數據庫的線程訪問，但這種會導致系統的吞吐率下降，需要實際情況使用。

緩存穿透

緩存穿透是指查詢一個一定不存在的數據，因為緩存中也無該數據的信息，則會直接去數據庫層進行查詢，從系統層面來看像是穿透了緩存層直接達到db，從而稱為緩存穿透，沒有了緩存層的保護，這種查詢一定不存在的數據對系統來說可能是一種危險，如果有人惡意用這種一定不存在的數據來頻繁請求系統，不，準確的說是攻擊系統，請求都會到達數據庫層導致db癱瘓從而引起系統故障。

解決方案：

緩存穿透業內的解決方案已經比較成熟，主要常用的有以下幾種：

布隆過濾器：類似于哈希表的一種算法，用所有可能的查詢條件生成一個bitmap，在進行數據庫查詢之前會使用這個bitmap進行過濾，如果不在其中則直接過濾，從而減輕數據庫層面的壓力。

空值緩存：一種比較簡單的解決辦法，在第一次查詢完不存在的數據后，將該key與對應的空值(null或者對象里只有key)也放入緩存中，只不過設定為較短的失效時間，例如幾分鐘，這樣則可以應對短時間的大量的該key攻擊，設置為較短的失效時間是因為該值可能業務無關，存在意義不大，且該次的查詢也未必是攻擊者發起，無過久存儲的必要，故可以早點失效。

總結

由于本篇文章屬于理論篇，所以全篇沒有一行代碼，但是文中提出來的基本上就是秒殺系統所發生過的，每個系統可能發生的問題不同而已。

本文轉載自微信公眾號「Java后端技術全棧」，可以通過以下二維碼關注。轉載本文請聯系Java后端技術全棧公眾號。