秒殺系統設計方案

秒殺系統設計方案
1、秒殺系統架構設計關鍵點
1．兩個問題，一個備選方案
（1）秒殺其實主要解決兩個問題
一個是併發讀，併發讀的核心理念是儘可能減小用戶到服務端來「讀」數據，或者讀更少的數據。
一個是併發寫，併發寫咱們在數據庫層面獨立出來一個庫，作特殊的處理。
（2）還要針對秒殺系統作一些保護，針對意料以外的狀況設計兜底案，以防止最壞的狀況發生。
2．從架構師的角度來看，要想打造超大流量併發讀寫、高性能、高可用的系統，咱們要遵循幾個原則
（1）請求的數據儘可能少
（2）請求數盡少
（3）而且不要有單點
3．技術角度上看「穩、準、快」
（1）高性能中高併發訪問很是關鍵，處理方式有如下4點
設計數據的動靜分離方案、
熱點的發現與隔離、
請求的削峯與分層過濾、
服務端的極致優化、
（2）一致性中商品減庫存的實現方式一樣關鍵，主要有如下兩種扣減方式
拍下減庫存
付款減庫存
（3）高可用還要設計一個備選來兜底
2、秒殺系統應該注意的5個原則（結合業務動態平衡）
1．數據要儘可能少
（1）用戶請求的數據能少就少
用戶請求的數據包括，上傳給系統的數據和系統返回的數據。用戶請求的數據儘可能少的緣由是，網絡上數據傳輸須要時間，不論是請求數據仍是返回數據都須要服務器作處理，服務器在作網絡通訊都要作壓縮和字符編碼，這些都很是消耗CPU，因此要減小傳輸的數據量。
（2）系統依賴的數據能少就少
系統要完成某些業務須要讀取和保存數據，通常須要和後臺服務及數據庫打交道。調用其餘服務會涉及數據的系列化和反序列化，而這些也是CPU的一大殺手，一樣也會增長延時。數據庫自己也容易是一個瓶頸，因此和數據庫打交道越少越好，數據越簡單、越小則越好。
2．請求數要儘可能少
（1）額外請求儘可能減小
瀏覽器每發出一個請求都會有一些消耗，如三次握手，有的時候頁面或者連接數限制，一些請求還須要串行加載等。域名不同的話，還涉及這些域名的DNS解析，可能會耗時更久。
（2）合併CSS和JavaScript文件
在URL中用逗號隔開，在服務端仍然是單個文件各自存放，服務端自動解析這個URL，合併成一個文件一塊兒返回。
3．路徑要儘可能短
（1）通過一個節點通常都會產生一個socket連接
縮短請求路徑不只能夠增長可用性，還能夠提高性能（序列化、反序列化），減小延時（網絡傳輸耗時）。
（2）RPC調用換成JVM調用
RPC調用換成JVM調用酌情處理。
4．依賴要儘可能少
（1）完成一次用戶請求必須依賴的系統或者服務儘可能減小
若依賴在緊急狀況下能夠去掉，好比：秒殺頁面，這個頁面必須強依賴商品信息、用戶信息，還有其餘優惠券、成交列表這些對秒殺不是非要不可的信息，在緊急狀況下能夠去掉。
（2）創建系統級別
咱們能夠給系統進行分級，好比：0 級系統、1 級系統、2 級系統、3 級系統，0 級系統若是是最重要的系統，那麼 0 級系統強依賴的系統也一樣是最重要的系統，以此類推。0 級系統要儘可能減小對 1 級系統的強依賴，防止重要的系統被不重要的系統拖垮。
5．不要有單點
（1）設計系統最重要的就是消除單點
單點意味着沒有備份，風險不可控
（2）避免單點的方案
避免服務和狀態綁定，服務無狀態化。好比：把機器和相關配置動態化，配置經過配置中心動態推送。
3、不一樣場景下的不一樣架構案例
1．好比從 1w/s 到了 10w/s 的量級
把秒殺系統獨立開發，針對性的作優化。系統部署上作機器集羣，秒殺流量不會影響正常商品購買。熱點數據單獨存放在一個獨立的緩存系統，提升性能。增長秒殺答題，防止有秒殺器搶單。
2．100w/s的請求量級
對頁面進行完全動靜分離，使秒殺時不須要刷新整個頁面，只須要點擊搶寶按鈕，把刷新的數據降到最少。服務端對秒殺商品進行本地緩存，不須要調用依賴系統的後臺服務獲取數據，甚至不須要去公共緩存集羣中查詢數據，這樣不只能夠減小系統調用，並且可以減小公共緩存集羣的壓力。增長系統限流保護，防止最壞狀況發生。
4、動靜分離可選方案
1．動態數據和靜態數據的定義
動態數據跟訪問者相關的個性化數據，靜態數據包括存放在硬盤上的html頁面，和與訪問者無關的由業務處理數據
2．靜態數據作緩存的要點
靜態數據緩存到離用戶最近的地方。能夠存在（瀏覽器、CDN、服務器Cache），
靜態化改造（直接緩存http連接，而不是僅僅緩存數據），
Web服務器直接緩存靜態數據（nginx、apache）。
3．動靜分離5個方面
URL惟一化（分區保存）
分離瀏覽者相關因素（是否登陸、登陸身份等，經過動態請求獲取）
分離時間因素（服務器輸出時間經過動態請求獲取）
異步化地域因素（經過異步獲取地域相關信息）
去掉Cookie，靜態頁面不含cookie（經過代碼軟件刪除）
4．靜態數據和動態數據組裝
在代理服務器上作動態數據請求，並將動態數據插入到靜態頁面中
瀏覽器發起動態請求，瀏覽器進行頁面組裝
5．動靜分離的幾種架構方案
實體機單機部署
統一cache
上CDN（有幾個問題：1，失效問題；2，命中率問題；3，發佈更新問題；）
5、針對性地處理好系統「熱點數據」二八原則
1．熱點數據處理
（1）發現靜態熱點數據的方式
經過報名方式篩選熱點商品，後臺系統對熱點數據進行預處理。
系統預測，系統天天排除top N的商品，後臺系統對熱點數據進行預處理。
（2）發現動態熱點數據的方式
構建一個異步系統，它能夠收集交易鏈路上的各個環節中的中間件產品的熱點key，如Nginx、緩存、RPC服務框架等這些中間件。
創建一個熱點上報和能夠按照需求訂閱的熱點服務的下發規範，主要目的是經過交易鏈路上各個系統訪問的時間差，把上游系統已經發現的熱點同傳給下游系統，提早作好保護。
將上游系統收集的熱點數據發送到熱點服務器，而後下游系統作熱點保護。
2．打造熱點發現系統注意事項
熱點服務後臺抓取數據日誌採用異步方式
熱點服務發現和中間件的熱點保護模塊並存
熱點發下要作到接近實時
3．處理熱點數據
（1）優化熱點數據
優化熱點數據最有效的方法就是緩存熱點數據，緩存數據能夠用LRU淘汰算法替換。
（2）限制
根據商品id作一致性Hash，放入不一樣的隊列中，防止因某些商品佔用太多的服務。
（3）隔離
將這種熱點數據隔離出來，不讓1%的請求影響到另外99%的請求。
隔離有如下幾個層次，業務隔離、系統隔離、數據隔離
6、流量削峯方案
1．排隊
把一步的操做變成兩步的操做，增長一步起到緩衝的做用。
2．答題
防止部分秒殺器做弊
延緩請求，請求量削峯
3．分層過濾
將動態請求的讀數據緩存在web端，過濾掉無效數據；
讀數據不作強一致校驗；
對寫數據進行基於時間的合理分片，過濾掉過時的失效請求；
對寫請求作限流保護，將超出系統承載能力的請求過濾掉；
對寫數據進行強一致校驗，只保留最後有效數據；
7、提升系統性能方案
1．影響性能的因素（服務器性能通常用QPS來衡量）
（1）一次響應的服務端耗時，對性能有影響的是CPU的執行時間
（2）處理請求的線程數，合理的併發線程數
8、減庫存設計核心邏輯
1．減庫存的3種方式，以及可能存在的問題
（1）下單減庫存，下單不付款（大型秒殺系統通常使用下單減庫存）
（2）付款減庫存，庫存超賣
（3）預扣庫存（下單後庫存保留必定時間）
2．秒殺減庫存的極致優化
（1）秒殺商品的減庫存邏輯很是單一，能夠再緩存系統完成扣減
（2）比較複雜的庫存扣減邏輯，要在數據庫中完成扣減
9、備選方案的設計
1．高可用建設應該從哪裏着手
（1）架構階段
主要考慮可擴展性和容錯性，避免出現單機
（2）編碼階段
主要考慮代碼的健壯性，涉及遠程調用要設置合理的超時退出
也要對調用的返回結果集有預期，防止返回的結果超出程序處理的範圍
（3）測試階段
保證測試用例的覆蓋度
保證最壞的狀況發生時，有相應的處理流程
（4）發佈階段
要有緊急的回滾機制
（5）運行階段
對系統的監控要準確及時
發現問題能準確報警，數據要準確詳細，以便排查問題
（6）故障發生
及時止損
及時恢復，並定位緣由解決問題