建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
秒殺架構(gòu)設計的七個必殺技
今天我從 7 個不同的維度，講講秒殺系統(tǒng)的架構(gòu)設計，主要知識點如下：
- Nginx + 前后端分離 + CDN 緩存 + 網(wǎng)關(guān)（限流+熔斷）
- 集群的路由層 + Redis（緩存熱點數(shù)據(jù)、分布式鎖)
- MQ 集群
- 業(yè)務處理層
- 數(shù)據(jù)庫層（讀寫分離、熱點隔離)
1. 秒殺業(yè)務的特點
- 瞬間大量的刷新頁面的操作
- 瞬間大量的搶寶的操作
- 可能有秒殺器的惡性競爭
2. 總體思路
2.1 削峰限流
- 前端+Redis攔截，只有redis扣減成功的請求才能進入到下游
- MQ堆積訂單，保護訂單處理層的負載，Consumer根據(jù)自己的消費能力來取Task，實際上下游的壓力就可控了。重點做好路由層和MQ的安全
- 引入答題驗證碼、請求的隨機休眠等措施，削峰填谷
安全保護
- 頁面和前端要做判斷，防止活動未開始就搶單，防止重復點擊按鈕連續(xù)搶單
- 防止秒殺器惡意搶單，IP限流、UserId限流限購、引入答題干擾答題器，并且對答題器答題時間做常理推斷
- IP黑名單、UserId黑名單功能
- 過載丟棄：QPS或者CPU等核心指標超過一定限額時，丟棄請求，避免服務器掛掉，保證大部分用戶可用
頁面優(yōu)化，動靜分離
- 秒殺商品的網(wǎng)頁內(nèi)容盡可能做的簡單：圖片小、js css 體積小數(shù)量少，內(nèi)容盡可能的做到動靜分離
- 秒殺的搶寶過程中做成異步刷新?lián)寣?，而不需要用戶刷新頁面來搶，降低服務器交互的壓?/li>
- 可以使用Nginx的動靜分離，不通過傳統(tǒng)web瀏覽器獲取靜態(tài)資源
- nginx開啟gzip壓縮，壓縮靜態(tài)資源，減少傳輸帶寬，提升傳輸速度
- 或者使用Varnish，把靜態(tài)資源緩存到內(nèi)存當中，避免靜態(tài)資源的獲取給服務器造成的壓力
異步處理
- redis搶單成功后，把后續(xù)的業(yè)務丟到線程池中異步的處理，提高搶單的響應速度
- 線程池處理時，把任務丟到MQ中，異步的等待各個子系統(tǒng)處理（訂單系統(tǒng)、庫存系統(tǒng)、支付系統(tǒng)、優(yōu)惠券系統(tǒng)）
異步操作有事務問題，本地事務和分布式事務，但是為了提升并發(fā)度，最好犧牲一致性。通過定時掃描統(tǒng)計日志，來發(fā)現(xiàn)有問題的訂單，并且及時處理
熱點分離
盡量的避免秒殺功能給正常功能帶來的影響，比如秒殺把服務器某個功能拖垮了。
分離可以提升系統(tǒng)的容災性，但是完全的隔離的改造成本太高了，盡量借助中間件的配置，來實現(xiàn)冷熱分離。
- 集群節(jié)點的分離：nginx配置讓秒殺業(yè)務走的集群節(jié)點和普通業(yè)務走的集群不一樣。
- MQ的分離：避免秒殺業(yè)務把消息隊列堆滿了，普通業(yè)務的交易延遲也特別厲害。
- 數(shù)據(jù)庫的分離：根據(jù)實際的秒殺的QPS來選擇，熱點數(shù)據(jù)分庫以后，增加了分布式事務的問題，以及查詢的時候跨庫查詢性能要差一些（ShardingJDBC有這種功能），所以要權(quán)衡以后再決定是否需要分庫
- 避免單點：各個環(huán)節(jié)都要盡力避免
- 降級：臨時關(guān)閉一些沒那么重要的功能，比如秒殺商品的轉(zhuǎn)贈功能、紅包的提現(xiàn)功能，待秒殺峰值過了，設置開關(guān)，再動態(tài)開放這些次要的功能
2.2 Nginx的設計細節(jié)
- 動靜分離，不走tomcat獲取靜態(tài)資源
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壓縮，減少靜態(tài)文件傳輸?shù)捏w積，節(jié)省帶寬，提高渲染速度
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;
配置集群負載和容災，設置失效重連的時間，失效后，定期不會再重試掛掉的節(jié)點，參數(shù)：
- fail_timeout默認為10s
- max_fails默認為1。就是說，只要某個server失效一次，則在接下來的10s內(nèi)，就不會分發(fā)請求到該server上
- proxy_connect_timeout 后端服務器連接的超時時間_發(fā)起握手等候響應超時時間
upstream netitcast.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://netitcast.com;
proxy_connect_timeout 1;
fail_timeout 5;
}
}
- 集成Varnish做靜態(tài)資源的緩存
- 集成tengine做過載的保護
2.3 頁面優(yōu)化細節(jié)
降低交互的壓力
- 盡量把js、css文件放在少數(shù)幾個里面，減少瀏覽器和后端交互獲取靜態(tài)資源的次數(shù)
- 盡量避免在秒殺商品頁面使用大的圖片，或者使用過多的圖片
安全控制
- 時間有效性驗證：未到秒殺時間不能進行搶單，并且同時程序后端也要做時間有效性驗證，因為網(wǎng)頁的時間和各自的系統(tǒng)時間決定，而且秒殺器可以通過繞開校驗直接調(diào)用搶單
- 異步搶單：通過點擊按鈕刷新?lián)寣殻皇撬⑿马撁娴姆绞綋寣殻ù痤}驗證碼等等也是ajax交互）
- 另外，搜索公眾號Linux就該這樣學后臺回復“猴子”，獲取一份驚喜禮包。
- redis做IP限流
- redis做UserId限流
2.4 Redis集群的應用
- 分布式鎖（悲觀鎖）
- 緩存熱點數(shù)據(jù)（庫存）：如果QPS太高的話，另一種方案是通過localcache，分布式狀態(tài)一致性通過數(shù)據(jù)庫來控制
分布式悲觀鎖（參考redis悲觀鎖的代碼）
- 悲觀鎖（因為肯定爭搶嚴重）
- Expire時間（搶到鎖后，立刻設置過期時間，防止某個線程的異常停擺，導致整個業(yè)務的停擺）
- 定時循環(huán)和快速反饋（for緩存有超時設置，每次超時后，重新讀取一次庫存，還有貨再進行第二輪的for循環(huán)爭奪，實現(xiàn)快速反饋，避免沒有貨了還在持續(xù)搶鎖）
異步處理訂單
- redis搶鎖成功后，記錄搶到鎖的用戶信息后，就可以直接釋放鎖，并反饋用戶，通過異步的方式來處理訂單，提升秒殺的效率，降低無意義的線程等待
- 為了避免異步的數(shù)據(jù)不同步，需要搶到鎖的時候，在redis里面緩存用戶信息列表，緩存結(jié)束后，觸發(fā)搶單成功用戶信息持久化，并且定時的比對一致性
2.5 消息隊列限流
消息隊列削峰限流(RocketMQ自帶的Consumer自帶線程池和限流措施)，集群。一般都是微服務，訂單中心、庫存中心、積分中心、用戶的商品中心
2.6 數(shù)據(jù)庫設計
- 拆分事務提高并發(fā)度
- 根據(jù)業(yè)務需求考慮分庫：讀寫分離、熱點隔離拆分，但是會引入分布式事務問題，以及跨庫操作的難度
要執(zhí)行的操作：扣減庫存、生成新訂單、生成待支付訂單、扣減優(yōu)惠券、積分變動
庫存表是數(shù)據(jù)庫并發(fā)的瓶頸所在，需要在事務控制上做權(quán)衡：可以把扣減庫存設置成一個獨立的事務，其它操作成一個大的事務（訂單、優(yōu)惠券、積分操作），提高并發(fā)度，但是要做好額外的check
update 庫存表 set 庫存=庫存-1 where id=** and 庫存>1
2.7 答題驗證碼的設計
- 可以防止秒殺器的干擾，讓更多用戶有機會搶到
- 延緩請求，每個人的反應時間不同，把瞬間流量分散開來了
驗證碼的設計可以分為2種：
- 驗證失敗重新刷新答題（12306）：服務器交互量大，每錯一次交互一次，但是可以大大降低秒殺器答題的可能性，因為沒有試錯這個功能，答題一直在變
- 驗證失敗提示失敗，但是不刷新答題的算法：要么答題成功，進入下單界面，要么提示打錯，繼續(xù)答題（不刷新答題，無須交互，用js驗證結(jié)果)。
這種方案，可以在加載題目的時候一起加載MD5加密的答案，然后后臺再校驗一遍，實現(xiàn)類似的防止作弊的效果。好處是不需要額外的服務器交互。
MD加密答案的算法里面要引入 userId PK這些因素進來來確保每次答案都不一樣而且沒有規(guī)律，避免秒殺器統(tǒng)計結(jié)果集
答題的驗證：除了驗證答案的正確性意外，還要統(tǒng)計反應時間，例如12306的難題，正常人類的答題速度最快是1.5s，那么，小于1s的驗證可以判定為機器驗證
3. 注意事項
為了提升并發(fā)，需要在事務上做妥協(xié)：
- 單機上拆分事務：比如扣減庫存表+(生成待支付訂單+優(yōu)惠券扣減+積分變動)是一個大的事務，為了提高并發(fā)，可以拆分為2個事務
- 分庫以后引入分布式事務問題,為了保證用戶體驗，最好還是通過日志分析來人工維護，否則阻塞太嚴重，并發(fā)差。
分享文章：秒殺架構(gòu)設計的七個必殺技
URL標題：http://www.5511xx.com/article/dhcosph.html
