Java生鮮電商平台-秒殺系統微服務架構設計與源碼解析實戰
Java生鮮電商平台- 什么是秒殺
通俗一點講就是網絡商家為促銷等目的組織的網上限時搶購活動
比如說京東秒殺，就是一種定時定量秒殺，在規定的時間內，無論商品是否秒殺完畢，該場次的秒殺活動都會結束。這種秒殺，對時間不是特別嚴格，只要下手快點，秒中的概率還是比較大的。
淘寶以前就做過一元搶購，一般都是限量 1 件商品，同時價格低到「令人發齒」，這種秒殺一般都在開始時間 1 到 3 秒內就已經搶光了，參與這個秒殺一般都是看運氣的，不必太強求
業務特點
瞬時並發量大
秒殺時會有大量用戶在同一時間進行搶購，瞬時並發訪問量突增 10 倍，甚至 100 倍以上都有。
庫存量少
一般秒殺活動商品量很少，這就導致了只有極少量用戶能成功購買到。
業務簡單
流程比較簡單，一般都是下訂單、扣庫存、支付訂單
技術難點
現有業務的沖擊
秒殺是營銷活動中的一種，如果和其他營銷活動應用部署在同一服務器上，肯定會對現有其他活動造成沖擊，極端情況下可能導致整個電商系統服務宕機
直接下訂單
下單頁面是一個正常的 URL 地址，需要控制在秒殺開始前，不能下訂單，只能瀏覽對應活動商品的信息。簡單來說，需要 Disable 訂單按鈕
頁面流量突增
秒殺活動開始前后，會有很多用戶請求對應商品頁面，會造成后台服務器的流量突增，同時對應的網絡帶寬增加，需要控制商品頁面的流量不會對后台服務器、DB、Redis 等組件的造成過大的壓力
架構設計思想
限流
由於活動庫存量一般都是很少，對應的只有少部分用戶才能秒殺成功。所以我們需要限制大部分用戶流量，只准少量用戶流量進入后端服務器
削峰
秒殺開始的那一瞬間，會有大量用戶沖擊進來，所以在開始時候會有一個瞬間流量峰值。如何把瞬間的流量峰值變得更平緩，是能否成功設計好秒殺系統的關鍵因素。實現流量削峰填谷，一般的采用緩存和 MQ 中間件來解決
異步
秒殺其實可以當做高並發系統來處理，在這個時候，可以考慮從業務上做兼容，將同步的業務，設計成異步處理的任務，提高網站的整體可用性
緩存
秒殺系統的瓶頸主要體現在下訂單、扣減庫存流程中。在這些流程中主要用到 OLTP 的數據庫，類似 MySQL、SQLServer、Oracle。由於數據庫底層采用 B+ 樹的儲存結構，對應我們隨機寫入與讀取的效率，相對較低。如果我們把部分業務邏輯遷移到內存的緩存或者 Redis 中，會極大的提高並發效率
整體架構
客戶端優化
秒殺頁面
秒殺活動開始前，其實就有很多用戶訪問該頁面了。如果這個頁面的一些資源，比如 CSS、JS、圖片、商品詳情等，都訪問后端服務器，甚至 DB 的話，服務肯定會出現不可用的情況。所以一般我們會把這個頁面整體進行靜態化，並將頁面靜態化之后的頁面分發到 CDN 邊緣節點上，起到壓力分散的作用
防止提前下單
防止提前下單主要是在靜態化頁面中加入一個 JS 文件引用，該 JS 文件包含活動是否開始的標記以及開始時的動態下單頁面的 URL 參數。同時，這個 JS 文件是不會被 CDN 系統緩存的，會一直請求后端服務的，所以這個 JS 文件一定要很小。當活動快開始的時候（比如提前），通過后台接口修改這個 JS 文件使之生效
API 接入層優化
客戶端優化，對於不是搞計算機方面的用戶還是可以防止住的。但是稍有一定網絡基礎的用戶就起不到作用了，因此服務端也需要加些對應控制，不能信任客戶端的任何操作。一般控制分為 2 大類
限制用戶維度訪問頻率
針對同一個用戶（ Userid 維度），做頁面級別緩存，單元時間內的請求，統一走緩存，返回同一個頁面
限制商品維度訪問頻率
大量請求同時間段查詢同一個商品時，可以做頁面級別緩存，不管下回是誰來訪問，只要是這個頁面就直接返回
SOA 服務層優化
上面兩層只能限制異常用戶訪問，如果秒殺活動運營的比較好，很多用戶都參加了，就會造成系統壓力過大甚至宕機，因此需要后端流量控制
對於后端系統的控制可以通過消息隊列、異步處理、提高並發等方式解決。對於超過系統水位線的請求，直接采取 「Fail-Fast」原則，拒絕掉
秒殺整體流程圖
秒殺系統核心在於層層過濾，逐漸遞減瞬時訪問壓力，減少最終對數據庫的沖擊。通過上面流程圖就會發現壓力最大的地方在哪里？
MQ 排隊服務，只要 MQ 排隊服務頂住，后面下訂單與扣減庫存的壓力都是自己能控制的，根據數據庫的壓力，可以定制化創建訂單消費者的數量，避免出現消費者數據量過多，導致數據庫壓力過大或者直接宕機。
庫存服務專門為秒殺的商品提供庫存管理，實現提前鎖定庫存，避免超賣的現象。同時，通過超時處理任務發現已搶到商品，但未付款的訂單，並在規定付款時間后，處理這些訂單，將恢復訂單商品對應的庫存量
Nginx優化
- 動靜分離，不走tomcat獲取靜態資源
server {
listen 8088; location ~ \.(gif|jpg|jpeg|png|bmp|swf)$ { root C:/Users/502764158/Desktop/test; } location ~ \.(jsp|do)$ { proxy_pass http://localhost:8082; } } } - gzip壓縮，減少靜態文件傳輸的體積，節省帶寬，提高渲染速度
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 3;
gzip_disable "MSIE [1-6]\."; gzip_types text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png; - 配置集群負載和容災，設置失效重連的時間，失效后，定期不會再重試掛掉的節點,參數
- fail_timeout默認為10s
- max_fails默認為1。就是說，只要某個server失效一次，則在接下來的10s內，就不會分發請求到該server上
- proxy_connect_timeout 后端服務器連接的超時時間_發起握手等候響應超時時間
upstream diancai.com {
#服務器集群名字 server 127.0.0.1:8080; server 127.0.0.1:38083; server 127.0.0.1:8083; } server { listen 88; server_name localhost; location / { proxy_pass http://diancai.com; proxy_connect_timeout 1; fail_timeout 5; } } - 集成Varnish做靜態資源的緩存
- 集成tengine做過載的保護
頁面優化
- 降低交互的壓力
- 盡量把js、css文件放在少數幾個里面，減少瀏覽器和后端交互獲取靜態資源的次數
- 盡量避免在秒殺商品頁面使用大的圖片，或者使用過多的圖片
- 安全控制
- 時間有效性驗證：未到秒殺時間不能進行搶單，並且同時程序后端也要做時間有效性驗證，因為網頁的時間和各自的系統時間決定，而且秒殺器可以通過繞開校驗直接調用搶單
- 異步搶單：通過點擊按鈕刷新搶寶，而不是刷新頁面的方式搶寶（答題驗證碼等等也是ajax交互）
- redis做IP限流
- redis做UserId限流
Redis集群
-
分布式鎖（悲觀鎖）
-
緩存熱點數據（庫存）：如果QPS太高的話，另一種方案是通過localcache，分布式狀態一致性通過數據庫來控制
-
分布式悲觀鎖（參考redis悲觀鎖的代碼）
- 悲觀鎖（因為肯定爭搶嚴重）
- Expire時間（搶到鎖后，立刻設置過期時間，防止某個線程的異常停擺，導致整個業務的停擺）
- 定時循環和快速反饋（for緩存有超時設置，每次超時后，重新讀取一次庫存，還有貨再進行第二輪的for循環爭奪，實現快速反饋，避免沒有貨了還在持續搶鎖）
- 異步處理訂單
- redis搶鎖成功后，記錄搶到鎖的用戶信息后，就可以直接釋放鎖，並反饋用戶，通過異步的方式來處理訂單，提升秒殺的效率，降低無意義的線程等待
- 為了避免異步的數據不同步，需要搶到鎖的時候，在redis里面緩存用戶信息列表，緩存結束后，觸發搶單成功用戶信息持久化，並且定時的比對一致性
消息隊列限流
消息隊列削峰限流(RocketMQ自帶的Consumer自帶線程池和限流措施)，集群。一般都是微服務，訂單中心、庫存中心、積分中心、用戶的商品中心
數據庫
- 拆分事務提高並發度
- 根據業務需求考慮分庫：讀寫分離、熱點隔離拆分，但是會引入分布式事務問題，以及跨庫操作的難度
要執行的操作：扣減庫存、生成新訂單、生成待支付訂單、扣減優惠券、積分變動
庫存表是數據庫並發的瓶頸所在，需要在事務控制上做權衡：可以把扣減庫存設置成一個獨立的事務，其它操作成一個大的事務（訂單、優惠券、積分操作），提高並發度，但是要做好額外的check
update 庫存表 set 庫存=庫存-1 where id=** and 庫存>1 - 為了提升並發，需要在事務上做妥協
單機上拆分事務：比如扣減庫存表+(生成待支付訂單+優惠券扣減+積分變動)是一個大的事務，為了提高並發，可以拆分為2個事務
分庫以后引入分布式事務問題,為了保證用戶體驗，最好還是通過日志分析來人工維護，否則阻塞太嚴重，並發差
答題驗證碼
- 可以防止秒殺器的干擾，讓更多用戶有機會搶到
- 延緩請求，每個人的反應時間不同，把瞬間流量分散開來了
- 驗證碼的設計可以分為2種
-
驗證失敗重新刷新答題（12306）：服務器交互量大，每錯一次交互一次，但是可以大大降低秒殺器答題的可能性，因為沒有試錯這個功能，答題一直在變
驗證失敗提示失敗，但是不刷新答題的算法：要么答題成功，進入下單界面，要么提示打錯，繼續答題（不刷新答題，無須交互，用js驗證結果)。
這種方案，可以在加載題目的時候一起加載MD5加密的答案，然后后台再校驗一遍，實現類似的防止作弊的效果。好處是不需要額外的服務器交互。
MD加密答案的算法里面要引入 userId PK這些因素進來來確保每次答案都不一樣而且沒有規律，避免秒殺器統計結果集 -
答題的驗證：除了驗證答案的正確性意外，還要統計反應時間，例如12306的難題，正常人類的答題速度最快是1.5s，那么，小於1s的驗證可以判定為機器驗證
總結
層層過濾，盡量將請求攔截在上游，降低下游的壓力，充分利用緩存與消息隊列，提高請求處理速度以及削峰填谷的作用
削峰限流
- 前端+Redis攔截，只有redis扣減成功的請求才能進入到下游
- MQ堆積訂單，保護訂單處理層的負載，Consumer根據自己的消費能力來取Task，實際上下游的壓力就可控了。重點做好路由層和MQ的安全
- 引入答題驗證碼、請求的隨機休眠等措施，削峰填谷
安全保護
- 頁面和前端要做判斷，防止活動未開始就搶單，防止重復點擊按鈕連續搶單
- 防止秒殺器惡意搶單，IP限流、UserId限流限購、引入答題干擾答題器，並且對答題器答題時間做常理推斷
- 過載丟棄，QPS或者CPU等核心指標超過一定限額時，丟棄請求，避免服務器掛掉，保證大部分用戶可用
頁面優化，動靜分離
- 秒殺商品的網頁內容盡可能做的簡單：圖片小、js css 體積小數量少，內容盡可能的做到動靜分離
- 秒殺的搶寶過程中做成異步刷新搶寶，而不需要用戶刷新頁面來搶，降低服務器交互的壓力
- 可以使用Nginx的動靜分離，不通過傳統web瀏覽器獲取靜態資源
- nginx開啟gzip壓縮，壓縮靜態資源，減少傳輸帶寬，提升傳輸速度
- 或者使用Varnish，把靜態資源緩存到內存當中，避免靜態資源的獲取給服務器造成的壓力
異步處理
- redis搶單成功后，把后續的業務丟到線程池中異步的處理，提高搶單的響應速度
- 線程池處理時，把任務丟到MQ中，異步的等待各個子系統處理（訂單系統、庫存系統、支付系統、優惠券系統），異步操作有事務問題，本地事務和分布式事務，但是為了提升並發度，最好犧牲一致性。通過定時掃描統計日志，來發現有問題的訂單，並且及時處理
熱點分離
盡量的避免秒殺功能給正常功能帶來的影響，比如秒殺把服務器某個功能拖垮了
分離可以提升系統的容災性，但是完全的隔離的改造成本太高了，盡量借助中間件的配置，來實現冷熱分離
- 集群節點的分離：nginx配置讓秒殺業務走的集群節點和普通業務走的集群不一樣。
- MQ的分離：避免秒殺業務把消息隊列堆滿了，普通業務的交易延遲也特別厲害。
- 數據庫的分離：根據實際的秒殺的QPS來選擇，熱點數據分庫以后，增加了分布式事務的問題，以及查詢的時候跨庫查詢性能要差一些（ShardingJDBC有這種功能），所以要權衡以后再決定是否需要分庫
避免單點
各個環節都要盡力避免
降級
臨時關閉一些沒那么重要的功能，比如秒殺商品的轉贈功能、紅包的提現功能，待秒殺峰值過了，設置開關，再動態開放這些次要的功能