寫在前面
很多小伙伴反饋說，高并發專題學了那么久，但是，在真正做專案時，仍然不知道如何下手處理高并發業務場景！甚至很多小伙伴仍然停留在只是簡單的提供介面（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很可能就會掛掉，那么，我們如何解決這個問題呢？
留下這個問題，歡迎大家在評論區交流~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/172294.html
標籤：java
上一篇：從0到1，阿里巴巴定制版的JVM高手實戰清單！深度廣度環環相扣
下一篇：學習Java在西安找作業可以嗎