高並行秒殺系統架構詳解，不是所有的秒殺都是秒殺！
寫在前面
很多小夥伴反饋說，高並行專題學了那麼久，但是，在真正做專案時，仍然不知道如何下手處理高並行業務場景！甚至很多小夥伴仍然停留在只是簡單的提供介面（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很可能就會掛掉，那麼，我們如何解決這個問題呢？
留下這個問題，歡迎大家在評論區交流~