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有這種功能），所以要權衡以后再決定是否需要分庫

避免單點

各個環節都要盡力避免

降級

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

轉載于:https://www.cnblogs.com/jurendage/p/11345887.html

總結

以上是生活随笔為你收集整理的Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。