Java生鮮電商平臺-秒殺系統微服務架構設計與源碼解析實戰

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優化

1. 動靜分離，不走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; } } } 

2. 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; 

3. 配置集羣負載和容災，設置失效重連的時間，失效後，按期不會再重試掛掉的節點,參數

• 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; } } 

4. 集成Varnish作靜態資源的緩存
5. 集成tengine作過載的保護

頁面優化

1. 下降交互的壓力

• 儘可能把js、css文件放在少數幾個裏面，減小瀏覽器和後端交互獲取靜態資源的次數
• 儘可能避免在秒殺商品頁面使用大的圖片，或者使用過多的圖片

2. 安全控制

• 時間有效性驗證：未到秒殺時間不能進行搶單，而且同時程序後端也要作時間有效性驗證，由於網頁的時間和各自的系統時間決定，並且秒殺器能夠經過繞開校驗直接調用搶單
• 異步搶單：經過點擊按鈕刷新搶寶，而不是刷新頁面的方式搶寶（答題驗證碼等等也是ajax交互）
• redis作IP限流
• redis作UserId限流

Redis集羣

1. 分佈式鎖（悲觀鎖）

2. 緩存熱點數據（庫存）：若是QPS過高的話，另外一種方案是經過localcache，分佈式狀態一致性經過數據庫來控制

3. 分佈式悲觀鎖（參考redis悲觀鎖的代碼）

• 悲觀鎖（由於確定爭搶嚴重）
• Expire時間（搶到鎖後，馬上設置過時時間，防止某個線程的異常停擺，致使整個業務的停擺）
• 定時循環和快速反饋（for緩存有超時設置，每次超時後，從新讀取一次庫存，還有貨再進行第二輪的for循環爭奪，實現快速反饋，避免沒有貨了還在持續搶鎖）

4. 異步處理訂單

• redis搶鎖成功後，記錄搶到鎖的用戶信息後，就能夠直接釋放鎖，並反饋用戶，經過異步的方式來處理訂單，提高秒殺的效率，下降無心義的線程等待
• 爲了不異步的數據不一樣步，須要搶到鎖的時候，在redis裏面緩存用戶信息列表，緩存結束後，觸發搶單成功用戶信息持久化，而且定時的比對一致性

消息隊列限流

消息隊列削峯限流(RocketMQ自帶的Consumer自帶線程池和限流措施)，集羣。通常都是微服務，訂單中心、庫存中心、積分中心、用戶的商品中心

數據庫

• 拆分事務提升併發度
• 根據業務需求考慮分庫：讀寫分離、熱點隔離拆分，可是會引入分佈式事務問題，以及跨庫操做的難度
  要執行的操做：扣減庫存、生成新訂單、生成待支付訂單、扣減優惠券、積分變更
  庫存表是數據庫併發的瓶頸所在，須要在事務控制上作權衡：能夠把扣減庫存設置成一個獨立的事務，其它操做成一個大的事務（訂單、優惠券、積分操做），提升併發度，可是要作好額外的check
  update 庫存表 set 庫存=庫存-1 where id=** and 庫存>1
• 爲了提高併發，須要在事務上作妥協
  單機上拆分事務：好比扣減庫存表+(生成待支付訂單+優惠券扣減+積分變更)是一個大的事務，爲了提升併發，能夠拆分爲2個事務
  分庫之後引入分佈式事務問題,爲了保證用戶體驗，最好仍是經過日誌分析來人工維護，不然阻塞太嚴重，併發差

答題驗證碼

1. 能夠防止秒殺器的干擾，讓更多用戶有機會搶到
2. 延緩請求，每一個人的反應時間不一樣，把瞬間流量分散開來了
3. 驗證碼的設計能夠分爲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有這種功能），因此要權衡之後再決定是否須要分庫

避免單點

各個環節都要盡力避免

降級

臨時關閉一些沒那麼重要的功能，好比秒殺商品的轉贈功能、紅包的提現功能，待秒殺峯值過了，設置開關，再動態開放這些次要的功能