高併發秒殺系統架構詳解，不是所有的秒殺都是秒殺！

寫在前面

很多小夥伴反饋說，高併發專題學了那麼久，但是，在真正做專案時，仍然不知道如何下手處理高併發業務場景！甚至很多小夥伴仍然停留在只是簡單的提供介面（CRUD）階段，不知道學習的併發知識如何運用到實際專案中，就更別提如何構建高併發系統了！

究竟什麼樣的系統算是高併發系統？今天，我們就一起解密高併發業務場景下典型的秒殺系統的架構，結合高併發專題下的其他文章，學以致用。

這邊還有各個知識點模組整理文件和更多大廠面試真題，有需要的朋友可以點一點下方連結免費領取

連結：1103806531暗號：CSDN

電商系統架構

在電商領域，存在著典型的秒殺業務場景，那何謂秒殺場景呢。簡單的來說就是一件商品的購買人數遠遠大於這件商品的庫存，而且這件商品在很短的時間內就會被搶購一空。 比如每年的618、雙11大促，小米新品促銷等業務場景，就是典型的秒殺業務場景。
我們可以將電商系統的架構簡化成下圖所示。

由圖所示，我們可以簡單的將電商系統的核心層分為：負載均衡層、應用層和持久層。接下來，我們就預估下每一層的併發量。

假如負載均衡層使用的是高效能的Nginx，則我們可以預估Nginx最大的併發度為：10W+，這裡是以萬為單位。

假設應用層我們使用的是Tomcat，而Tomcat的最大併發度可以預估為800左右，這裡是以百為單位。

假設持久層的快取使用的是Redis，資料庫使用的是MySQL，MySQL的最大併發度可以預估為1000左右，以千為單位。Redis的最大併發度可以預估為5W左右，以萬為單位。

所以，負載均衡層、應用層和持久層各自的併發度是不同的，那麼，為了提升系統的總體併發度和快取，我們通常可以採取哪些方案呢？

（1）系統擴容

系統擴容包括垂直擴容和水平擴容，增加裝置和機器配置，絕大多數的場景有效。

（2）快取

本地快取或者集中式快取，減少網路IO，基於記憶體讀取資料。大部分場景有效。

（3）讀寫分離

採用讀寫分離，分而治之，增加機器的並行處理能力。

秒殺系統的特點

秒殺系統的業務特點

秒殺系統的技術特點

由於篇幅有限，這一部分省略，需要完整版的朋友可以點一點下方連結免費領取

連結：1103806531暗號：CSDN

秒殺三階段

通常，從秒殺開始到結束，往往會經歷三個階段：

準備階段：這個階段也叫作系統預熱階段，此時會提前預熱秒殺系統的業務資料，往往這個時候，使用者會不斷重新整理秒殺頁面，來檢視秒殺活動是否已經開始。在一定程度上，通過使用者不斷重新整理頁面的操作，可以將一些資料儲存到Redis中進行預熱。

秒殺階段：這個階段主要是秒殺活動的過程，會產生瞬時的高併發流量，對系統資源會造成巨大的衝擊，所以，在秒殺階段一定要做好系統防護。

結算階段： 完成秒殺後的資料處理工作，比如資料的一致性問題處理，異常情況處理，商品的回倉處理等。

針對這種短時間內大流量的系統來說，就不太適合使用系統擴容了，因為即使系統擴容了，也就是在很短的時間內會使用到擴容後的系統，大部分時間內，系統無需擴容即可正常訪問。 那麼，我們可以採取哪些方案來提升系統的秒殺效能呢？

秒殺系統方案

針對秒殺系統的特點，我們可以採取如下的措施來提升系統的效能。

（1）非同步解耦

將整體流程進行拆解，核心流程通過佇列方式進行控制。

（2）限流防刷

控制網站整體流量，提高請求的門檻，避免系統資源耗盡。

（3）資源控制

將整體流程中的資源排程進行控制，揚長避短。

由於應用層能夠承載的併發量比快取的併發量少很多。所以，在高併發系統中，我們可以直接使用OpenResty由負載均衡層訪問快取，避免了呼叫應用層的效能損耗。 同時，由於秒殺系統中，商品數量比較少，我們也可以使用動態渲染技術，CDN技術來加速網站的訪問效能。
如果在秒殺活動開始時，併發量太高時，我們可以將使用者的請求放入佇列中進行處理，併為使用者彈出排隊頁面。

秒殺系統時序圖

網上很多的秒殺系統和對秒殺系統的解決方案，並不是真正的秒殺系統，他們採用的只是同步處理請求的方案，一旦併發量真的上來了，他們所謂的秒殺系統的效能會急劇下降。我們先來看一下秒殺系統在同步下單時的時序圖。

同步下單流程

1.使用者發起秒殺請求

在同步下單流程中，首先，使用者發起秒殺請求。商城服務需要依次執行如下流程來處理秒殺請求的業務。

（1）識別驗證碼是否正確

商城服務判斷使用者發起秒殺請求時提交的驗證碼是否正確。

（2）判斷活動是否已經結束

驗證當前秒殺活動是否已經結束。

（3）驗證訪問請求是否處於黑名單

在電商領域中，存在著很多的惡意競爭，也就是說，其他商家可能會通過不正當手段來惡意請求秒殺系統，佔用系統大量的頻寬和其他系統資源。此時，就需要使用風控系統等實現黑名單機制。為了簡單，也可以使用攔截器統計訪問頻次實現黑名單機制。

（4）驗證真實庫存是否足夠

系統需要驗證商品的真實庫存是否足夠，是否能夠支援本次秒殺活動的商品庫存量。

（5）扣減快取中的庫存

在秒殺業務中，往往會將商品庫存等資訊存放在快取中，此時，還需要驗證秒殺活動使用的商品庫存是否足夠，並且需要扣減秒殺活動的商品庫存數量。

（6）計算秒殺的價格

由於在秒殺活動中，商品的秒殺價格和商品的真實價格存在差異，所以，需要計算商品的秒殺價格。

注意：如果在秒殺場景中，系統涉及的業務更加複雜的話，會涉及更多的業務操作，這裡，我只是列舉出一些常見的業務操作。

2.提交訂單

（1）訂單入口

將使用者提交的訂單資訊儲存到資料庫中。

（2）扣減真實庫存

訂單入庫後，需要在商品的真實庫存中將本次成功下單的商品數量扣除。

如果我們使用上述流程開發了一個秒殺系統，當使用者發起秒殺請求時，由於系統每個業務流程都是序列執行的，整體上系統的效能不會太高，當併發量太高時，我們會為使用者彈出下面的排隊頁面，來提示使用者進行等待。

由於時間關係，沒有寫的很詳細，有需要完整版的朋友可以點一點下方連結免費領取

連結：1103806531暗號：CSDN

高併發“黑科技”與致勝奇招

假設，在秒殺系統中我們使用Redis實現快取，假設Redis的讀寫併發量在5萬左右。我們的商城秒殺業務需要支援的併發量在100萬左右。如果這100萬的併發全部打入Redis中，Redis很可能就會掛掉，那麼，我們如何解決這個問題呢？

留下這個問題，歡迎大家在評論區交流~