## 寫在前面 > 很多小夥伴反饋說，高併發專題學了那麼久，但是，在真正做專案時，仍然不知道如何下手處理高併發業務場景！甚至很多小夥伴仍然停留在只是簡單的提供介面（CRUD）階段，不知道學習的併發知識如何運用到實際專案中，就更別提如何構建高併發系統了！ 究竟什麼樣的系統算是高併發系統？今天，我們就一起解密高併發業務場景下典型的秒殺系統的架構，結合高併發專題下的其他文章，學以致用。 ## 電商系統架構 在電商領域，存在著典型的秒殺業務場景，那何謂秒殺場景呢。簡單的來說就是一件商品的購買人數遠遠大於這件商品的庫存，而且這件商品在很短的時間內就會被搶購一空。 比如每年的618、雙11大促，小米新品促銷等業務場景，就是典型的秒殺業務場景。 我們可以將電商系統的架構簡化成下圖所示。  由圖所示，我們可以簡單的將電商系統的核心層分為：負載均衡層、應用層和持久層。接下來，我們就預估下每一層的併發量。 * 假如負載均衡層使用的是高效能的Nginx，則我們可以預估Nginx最大的併發度為：10W+，這裡是以萬為單位。 * 假設應用層我們使用的是Tomcat，而Tomcat的最大併發度可以預估為800左右，這裡是以百為單位。 * 假設持久層的快取使用的是Redis，資料庫使用的是MySQL，MySQL的最大併發度可以預估為1000左右，以千為單位。Redis的最大併發度可以預估為5W左右，以萬為單位。 所以，負載均衡層、應用層和持久層各自的併發度是不同的，那麼，為了提升系統的總體併發度和快取，我們通常可以採取哪些方案呢？ **（1）系統擴容** 系統擴容包括垂直擴容和水平擴容，增加裝置和機器配置，絕大多數的場景有效。 **（2）快取** 本地快取或者集中式快取，減少網路IO，基於記憶體讀取資料。大部分場景有效。 **（3）讀寫分離** 採用讀寫分離，分而治之，增加機器的並行處理能力。 ## 秒殺系統的特點 對於秒殺系統來說，我們可以從**業務和技術**兩個角度來闡述其自身存在的一些特點。 ### 秒殺系統的業務特點 這裡，我們可以使用12306網站來舉例，每年春運時，12306網站的訪問量是非常大的，但是網站平時的訪問量卻是比較平緩的，也就是說，每年春運時節，12306網站的訪問量會出現瞬時突增的現象。 再比如，小米秒殺系統，在上午10點開售商品，10點前的訪問量比較平緩，10點時同樣會出現併發量瞬時突增的現象。 所以，秒殺系統的流量和併發量我們可以使用下圖來表示。  由圖可以看出，秒殺系統的併發量存在瞬時凸峰的特點，也叫做流量突刺現象。 我們可以將秒殺系統的特點總結如下。  **（1）限時、限量、限價** 在規定的時間內進行；秒殺活動中商品的數量有限；商品的價格會遠遠低於原來的價格，也就是說，在秒殺活動中，商品會以遠遠低於原來的價格出售。 例如，秒殺活動的時間僅限於某天上午10點到10點半，商品數量只有10萬件，售完為止，而且商品的價格非常低，例如：1元購等業務場景。 **限時、限量和限價可以單獨存在，也可以組合存在。** **（2）活動預熱** 需要提前配置活動；活動還未開始時，使用者可以檢視活動的相關資訊；秒殺活動開始前，對活動進行大力宣傳。 **（3）持續時間短** 購買的人數數量龐大；商品會迅速售完。 在系統流量呈現上，就會出現一個突刺現象，此時的併發訪問量是非常高的，大部分秒殺場景下，商品會在極短的時間內售完。 ### 秒殺系統的技術特點 我們可以將秒殺系統的技術特點總結如下。  **（1）瞬時併發量非常高** 大量使用者會在同一時間搶購商品；瞬間併發峰值非常高。 **（2）讀多寫少** 系統中商品頁的訪問量巨大；商品的可購買數量非常少；庫存的查詢訪問數量遠遠大於商品的購買數量。 在商品頁中往往會加入一些限流措施，例如早期的秒殺系統商品頁會加入驗證碼來平滑前端對系統的訪問流量，近期的秒殺系統商品詳情頁會在使用者開啟頁面時，提示使用者登入系統。這都是對系統的訪問進行限流的一些措施。 **（3）流程簡單** 秒殺系統的業務流程一般比較簡單；總體上來說，秒殺系統的業務流程可以概括為：下單減庫存。 ## 秒殺三階段 通常，從秒殺開始到結束，往往會經歷三個階段： * **準備階段**：這個階段也叫作系統預熱階段，此時會提前預熱秒殺系統的業務資料，往往這個時候，使用者會不斷重新整理秒殺頁面，來檢視秒殺活動是否已經開始。在一定程度上，通過使用者不斷重新整理頁面的操作，可以將一些資料儲存到Redis中進行預熱。 * **秒殺階段**：這個階段主要是秒殺活動的過程，會產生瞬時的高併發流量，對系統資源會造成巨大的衝擊，所以，在秒殺階段一定要做好系統防護。 * **結算階段：** 完成秒殺後的資料處理工作，比如資料的一致性問題處理，異常情況處理，商品的回倉處理等。 針對這種短時間內大流量的系統來說，就不太適合使用系統擴容了，因為即使系統擴容了，也就是在很短的時間內會使用到擴容後的系統，大部分時間內，系統無需擴容即可正常訪問。 那麼，我們可以採取哪些方案來提升系統的秒殺效能呢？ ## 秒殺系統方案 針對秒殺系統的特點，我們可以採取如下的措施來提升系統的效能。  **（1）非同步解耦** 將整體流程進行拆解，核心流程通過佇列方式進行控制。 **（2）限流防刷** 控制網站整體流量，提高請求的門檻，避免系統資源耗盡。 **（3）資源控制** 將整體流程中的資源排程進行控制，揚長避短。 由於應用層能夠承載的併發量比快取的併發量少很多。所以，在高併發系統中，我們可以直接使用OpenResty由負載均衡層訪問快取，避免了呼叫應用層的效能損耗。大家可以到[https://openresty.org/cn/](https://openresty.org/cn/)來了解有關OpenResty更多的知識。同時，由於秒殺系統中，商品數量比較少，我們也可以使用動態渲染技術，CDN技術來加速網站的訪問效能。 如果在秒殺活動開始時，併發量太高時，我們可以將使用者的請求放入佇列中進行處理，併為使用者彈出排隊頁面。 

注：圖片來自魅族

## 秒殺系統時序圖 網上很多的秒殺系統和對秒殺系統的解決方案，並不是真正的秒殺系統，他們採用的只是同步處理請求的方案，一旦併發量真的上來了，他們所謂的秒殺系統的效能會急劇下降。我們先來看一下秒殺系統在同步下單時的時序圖。 ### 同步下單流程  ##### 1.使用者發起秒殺請求 在同步下單流程中，首先，使用者發起秒殺請求。商城服務需要依次執行如下流程來處理秒殺請求的業務。 **（1）識別驗證碼是否正確** 商城服務判斷使用者發起秒殺請求時提交的驗證碼是否正確。 **（2）判斷活動是否已經結束** 驗證當前秒殺活動是否已經結束。 **（3）驗證訪問請求是否處於黑名單** 在電商領域中，存在著很多的惡意競爭，也就是說，其他商家可能會通過不正當手段來惡意請求秒殺系統，佔用系統大量的頻寬和其他系統資源。此時，就需要使用風控系統等實現黑名單機制。為了簡單，也可以使用攔截器統計訪問頻次實現黑名單機制。 **（4）驗證真實庫存是否足夠** 系統需要驗證商品的真實庫存是否足夠，是否能夠支援本次秒殺活動的商品庫存量。 **（5）扣減快取中的庫存** 在秒殺業務中，往往會將商品庫存等資訊存放在快取中，此時，還需要驗證秒殺活動使用的商品庫存是否足夠，並且需要扣減秒殺活動的商品庫存數量。 **（6）計算秒殺的價格** 由於在秒殺活動中，商品的秒殺價格和商品的真實價格存在差異，所以，需要計算商品的秒殺價格。 **注意：如果在秒殺場景中，系統涉及的業務更加複雜的話，會涉及更多的業務操作，這裡，我只是列舉出一些常見的業務操作。** ##### 2.提交訂單 **（1）訂單入口** 將使用者提交的訂單資訊儲存到資料庫中。 **（2）扣減真實庫存** 訂單入庫後，需要在商品的真實庫存中將本次成功下單的商品數量扣除。 如果我們使用上述流程開發了一個秒殺系統，當用戶發起秒殺請求時，由於系統每個業務流程都是序列執行的，整體上系統的效能不會太高，當併發量太高時，我們會為使用者彈出下面的排隊頁面，來提示使用者進行等待。 

注：圖片來自魅族

此時的排隊時間可能是15秒，也可能是30秒，甚至是更長時間。這就存在一個問題：在使用者發起秒殺請求到伺服器返回結果的這段時間內，客戶端和伺服器之間的連線不會被釋放，這就會佔大量佔用伺服器的資源。 **網上很多介紹如何實現秒殺系統的文章都是採用的這種方式，那麼，這種方式能做秒殺系統嗎？答案是可以做，但是這種方式支撐的併發量並不是太高。此時，有些網友可能會問：我們公司就是這樣做的秒殺系統啊！上線後一直在用，沒啥問題啊！我想說的是：使用同步下單方式確實可以做秒殺系統，但是同步下單的效能不會太高。之所以你們公司採用同步下單的方式做秒殺系統沒出現大的問題，那是因為你們的秒殺系統的併發量沒達到一定的量級，也就是說，你們的秒殺系統的併發量其實並不高。** 所以，很多所謂的秒殺系統，存在著秒殺的業務，但是稱不上真正的秒殺系統，原因就在於他們使用的是同步的下單流程，限制了系統的併發流量。之所以上線後沒出現太大的問題，是因為系統的併發量不高，不足以壓死整個系統。 **如果12306、淘寶、天貓、京東、小米等大型商城的秒殺系統是這麼玩的話，那麼，他們的系統遲早會被玩死，他們的系統工程師不被開除才怪！所以，在秒殺系統中，這種同步處理下單的業務流程的方案是不可取的。** **以上就是同步下單的整個流程操作，如果下單流程更加複雜的話，就會涉及到更多的業務操作。** ### 非同步下單流程 既然同步下單流程的秒殺系統稱不上真正的秒殺系統，那我們就需要採用非同步的下單流程了。非同步的下單流程不會限制系統的高併發流量。  ##### 1.使用者發起秒殺請求 使用者發起秒殺請求後，商城服務會經過如下業務流程。 **（1）檢測驗證碼是否正確** 使用者發起秒殺請求時，會將驗證碼一同傳送過來，系統會檢驗驗證碼是否有效，並且是否正確。 **（2）是否限流** 系統會對使用者的請求進行是否限流的判斷，這裡，我們可以通過判斷訊息佇列的長度來進行判斷。因為我們將使用者的請求放在了訊息佇列中，訊息佇列中堆積的是使用者的請求，我們可以根據當前訊息佇列中存在的待處理的請求數量來判斷是否需要對使用者的請求進行限流處理。 例如，在秒殺活動中，我們出售1000件商品，此時在訊息佇列中存在1000個請求，如果後續仍然有使用者發起秒殺請求，則後續的請求我們可以不再處理，直接向用戶返回商品已售完的提示。  所以，使用限流後，我們可以更快的處理使用者的請求和釋放連線的資源。 **（3）傳送MQ** 使用者的秒殺請求通過前面的驗證後，我們就可以將使用者的請求引數等資訊傳送到MQ中進行非同步處理，同時，向用戶響應結果資訊。在商城服務中，會有專門的非同步任務處理模組來消費訊息佇列中的請求，並處理後續的非同步流程。 在使用者發起秒殺請求時，非同步下單流程比同步下單流程處理的業務操作更少，它將後續的操作通過MQ傳送給非同步處理模組進行處理，並迅速向用戶返回響應結果，釋放請求連線。 ##### 2.非同步處理 我們可以將下單流程的如下操作進行非同步處理。 （1）判斷活動是否已經結束 （2）判斷本次請求是否處於系統黑名單，為了防止電商領域同行的惡意競爭可以為系統增加黑名單機制，將惡意的請求放入系統的黑名單中。可以使用攔截器統計訪問頻次來實現。 （3）扣減快取中的秒殺商品的庫存數量。 （4）生成秒殺Token，這個Token是綁定當前使用者和當前秒殺活動的，只有生成了秒殺Token的請求才有資格進行秒殺活動。 這裡我們引入了非同步處理機制，**在非同步處理中，系統使用多少資源，分配多少執行緒來處理相應的任務，是可以進行控制的。** ##### 3.短輪詢查詢秒殺結果 這裡，可以採取客戶端短輪詢查詢是否獲得秒殺資格的方案。例如，客戶端可以每隔3秒鐘輪詢請求伺服器，查詢是否獲得秒殺資格，這裡，我們在伺服器的處理就是判斷當前使用者是否存在秒殺Token，如果伺服器為當前使用者生成了秒殺Token，則當前使用者存在秒殺資格。否則繼續輪詢查詢，直到超時或者伺服器返回商品已售完或者無秒殺資格等資訊為止。 採用短輪詢查詢秒殺結果時，在頁面上我們同樣可以提示使用者排隊處理中，但是此時客戶端會每隔幾秒輪詢伺服器查詢秒殺資格的狀態，相比於同步下單流程來說，無需長時間佔用請求連線。 此時，**可能會有網友會問：採用短輪詢查詢的方式，會不會存在直到超時也查詢不到是否具有秒殺資格的狀態呢？答案是：有可能！** 這裡我們試想一下秒殺的真實場景，商家參加秒殺活動本質上不是為了賺錢，而是提升商品的銷量和商家的知名度，吸引更多的使用者來買自己的商品。所以，我們不必保證使用者能夠100%的查詢到是否具有秒殺資格的狀態。 ##### 4.秒殺結算 **（1）驗證下單Token** 客戶端提交秒殺結算時，會將秒殺Token一同提交到伺服器，商城服務會驗證當前的秒殺Token是否有效。 **（2）加入秒殺購物車** 商城服務在驗證秒殺Token合法並有效後，會將使用者秒殺的商品新增到秒殺購物車。 ##### 5.提交訂單 **（1）訂單入庫** 將使用者提交的訂單資訊儲存到資料庫中。 **（2）刪除Token** 秒殺商品訂單入庫成功後，刪除秒殺Token。 **這裡大家可以思考一個問題：我們為什麼只在非同步下單流程的粉色部分採用非同步處理，而沒有在其他部分採取非同步削峰和填谷的措施呢？** 這是因為在非同步下單流程的設計中，無論是在產品設計上還是在介面設計上，我們在使用者發起秒殺請求階段對使用者的請求進行了限流操作，可以說，系統的限流操作是非常前置的。在使用者發起秒殺請求時進行了限流，系統的高峰流量已經被平滑解決了，再往後走，其實系統的併發量和系統流量並不是非常高了。 **所以，網上很多的文章和帖子中在介紹秒殺系統時，說是在下單時使用非同步削峰來進行一些限流操作，那都是在扯淡！ 因為下單操作在整個秒殺系統的流程中屬於比較靠後的操作了，限流操作一定要前置處理，在秒殺業務後面的流程中做限流操作是沒啥卵用的。** ## 高併發“黑科技”與致勝奇招 假設，在秒殺系統中我們使用Redis實現快取，假設Redis的讀寫併發量在5萬左右。我們的商城秒殺業務需要支援的併發量在100萬左右。如果這100萬的併發全部打入Redis中，Redis很可能就會掛掉，那麼，我們如何解決這個問題呢？接下來，我們就一起來探討這個問題。 > 在高併發的秒殺系統中，如果採用Redis快取資料，則Redis快取的併發處理能力是關鍵，因為很多的字首操作都需要訪問Redis。而非同步削峰只是基本的操作，關鍵還是要保證Redis的併發處理能力。 **解決這個問題的關鍵思想就是：分而治之，將商品庫存分開放。** ### 暗度陳倉 我們在Redis中儲存秒殺商品的庫存數量時，可以將秒殺商品的庫存進行“分割”儲存來提升Redis的讀寫併發量。 例如，原來的秒殺商品的id為10001，庫存為1000件，在Redis中的儲存為(10001, 1000)，我們將原有的庫存分割為5份，則每份的庫存為200件，此時，我們在Redia中儲存的資訊為(10001_0, 200)，(10001_1, 200)，(10001_2, 200)，(10001_3, 200)，(10001_4, 200)。  此時，我們將庫存進行分割後，每個分割後的庫存使用商品id加上一個數字標識來儲存，這樣，在對儲存商品庫存的每個Key進行Hash運算時，得出的Hash結果是不同的，這就說明，儲存商品庫存的Key有很大概率不在Redis的同一個槽位中，這就能夠提升Redis處理請求的效能和併發量。 分割庫存後，我們還需要在Redis中儲存一份商品id和分割庫存後的Key的對映關係，此時對映關係的Key為商品的id，也就是10001，Value為分割庫存後儲存庫存資訊的Key，也就是10001_0，10001_1，10001_2，10001_3，10001_4。在Redis中我們可以使用List來儲存這些值。 在真正處理庫存資訊時，我們可以先從Redis中查詢出秒殺商品對應的分割庫存後的所有Key，同時使用AtomicLong來記錄當前的請求數量，使用請求數量對從Redia中查詢出的秒殺商品對應的分割庫存後的所有Key的長度進行求模運算，得出的結果為0，1，2，3，4。再在前面拼接上商品id就可以得出真正的庫存快取的Key。此時，就可以根據這個Key直接到Redis中獲取相應的庫存資訊。 ### 移花接木 在高併發業務場景中，我們可以直接使用Lua指令碼庫（OpenResty）從負載均衡層直接訪問快取。 這裡，我們思考一個場景：如果在秒殺業務場景中，秒殺的商品被瞬間搶購一空。此時，使用者再發起秒殺請求時，如果系統由負載均衡層請求應用層的各個服務，再由應用層的各個服務訪問快取和資料庫，其實，本質上已經沒有任何意義了，因為商品已經賣完了，再通過系統的應用層進行層層校驗已經沒有太多意義了！！而應用層的併發訪問量是以百為單位的，這又在一定程度上會降低系統的併發度。 為了解決這個問題，此時，**我們可以在系統的負載均衡層取出使用者傳送請求時攜帶的使用者id，商品id和秒殺活動id等資訊，直接通過Lua指令碼等技術來訪問快取中的庫存資訊。如果秒殺商品的庫存小於或者等於0，則直接返回使用者商品已售完的提示資訊，而不用再經過應用層的層層校驗了。** 針對這個架構，我們可以參見本文中的電商系統的架構圖（正文開始的第一張圖）。 ### Redis助力秒殺系統 我們可以在Redis中設計一個Hash資料結構，來支援商品庫存的扣減操作，如下所示。 ```bash seckill:goodsStock:${goodsId}{ totalCount:200, initStatus:0, seckillCount:0 } ``` 在我們設計的Hash資料結構中，有三個非常主要的屬性。 * totalCount：表示參與秒殺的商品的總數量，在秒殺活動開始前，我們就需要提前將此值載入到Redis快取中。 * initStatus：我們把這個值設計成一個布林值。秒殺開始前，這個值為0，表示秒殺未開始。可以通過定時任務或者後臺操作，將此值修改為1，則表示秒殺開始。 * seckillCount：表示秒殺的商品數量，在秒殺過程中，此值的上限為totalCount，當此值達到totalCount時，表示商品已經秒殺完畢。 我們可以通過下面的程式碼片段在秒殺預熱階段，將要參與秒殺的商品資料載入的快取。 ```java /** * @author binghe * @description 秒殺前構建商品快取程式碼示例 */ public class SeckillCacheBuilder{ private static final String GOODS_CACHE = "seckill:goodsStock:"; private String getCacheKey(String id) { return GOODS_CACHE.concat(id); } public void prepare(String id, int totalCount) { String key = getCacheKey(id); Map