秒殺系統設計方案

秒殺系統設計方案
一、秒殺系統架構設計關鍵點
1．兩個問題，一個備選方案
（1）秒殺其實主要解決兩個問題
一個是并發讀，并發讀的核心理念是盡量減少用戶到服務端來“讀”數據，或者讀更少的數據。
一個是并發寫，并發寫我們在數據庫層面獨立出來一個庫，做特殊的處理。
（2）還要針對秒殺系統做一些保護，針對意料之外的情況設計兜底案，以防止最壞的情況發生。
2．從架構師的角度來看，要想打造超大流量并發讀寫、高性能、高可用的系統，我們要遵循幾個原則
（1）請求的數據盡量少
（2）請求數盡少
（3）并且不要有單點
3．技術角度上看“穩、準、快”
（1）高性能中高并發訪問非常關鍵，處理方式有以下4點
設計數據的動靜分離方案、
熱點的發現與隔離、
請求的削峰與分層過濾、
服務端的極致優化、
（2）一致性中商品減庫存的實現方式同樣關鍵，主要有以下兩種扣減方式
拍下減庫存
付款減庫存
（3）高可用還要設計一個備選來兜底
二、秒殺系統應該注意的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）避免單點的方案
避免服務和狀態綁定，服務無狀態化。比如：把機器和相關配置動態化，配置通過配置中心動態推送。
三、不同場景下的不同架構案例
1．比如從 1w/s 到了 10w/s 的量級
把秒殺系統獨立開發，針對性的做優化。系統部署上做機器集群，秒殺流量不會影響正常商品購買。熱點數據單獨存放在一個獨立的緩存系統，提高性能。增加秒殺答題，防止有秒殺器搶單。
2．100w/s的請求量級
對頁面進行徹底動靜分離，使秒殺時不需要刷新整個頁面，只需要點擊搶寶按鈕，把刷新的數據降到最少。服務端對秒殺商品進行本地緩存，不需要調用依賴系統的后臺服務獲取數據，甚至不需要去公共緩存集群中查詢數據，這樣不僅可以減少系統調用，而且能夠減少公共緩存集群的壓力。增加系統限流保護，防止最壞情況發生。
四、動靜分離可選方案
1．動態數據和靜態數據的定義
動態數據跟訪問者相關的個性化數據，靜態數據包括存放在硬盤上的html頁面，和與訪問者無關的由業務處理數據
2．靜態數據做緩存的要點
靜態數據緩存到離用戶最近的地方。可以存在（瀏覽器、CDN、服務器Cache），
靜態化改造（直接緩存http鏈接，而不是僅僅緩存數據），
Web服務器直接緩存靜態數據（nginx、apache）。
3．動靜分離5個方面
URL唯一化（分區保存）
分離瀏覽者相關因素（是否登錄、登錄身份等，通過動態請求獲取）
分離時間因素（服務器輸出時間通過動態請求獲取）
異步化地域因素（通過異步獲取地域相關信息）
去掉Cookie，靜態頁面不含cookie（通過代碼軟件刪除）
4．靜態數據和動態數據組裝
在代理服務器上做動態數據請求，并將動態數據插入到靜態頁面中
瀏覽器發起動態請求，瀏覽器進行頁面組裝
5．動靜分離的幾種架構方案
實體機單機部署
統一cache
上CDN（有幾個問題：1，失效問題；2，命中率問題；3，發布更新問題；）
五、針對性地處理好系統“熱點數據”二八原則
1．熱點數據處理
（1）發現靜態熱點數據的方式
通過報名方式篩選熱點商品，后臺系統對熱點數據進行預處理。
系統預測，系統每天排除top N的商品，后臺系統對熱點數據進行預處理。
（2）發現動態熱點數據的方式
構建一個異步系統，它可以收集交易鏈路上的各個環節中的中間件產品的熱點key，如Nginx、緩存、RPC服務框架等這些中間件。
建立一個熱點上報和可以按照需求訂閱的熱點服務的下發規范，主要目的是通過交易鏈路上各個系統訪問的時間差，把上游系統已經發現的熱點同傳給下游系統，提前做好保護。
將上游系統收集的熱點數據發送到熱點服務器，然后下游系統做熱點保護。
2．打造熱點發現系統注意事項
熱點服務后臺抓取數據日志采用異步方式
熱點服務發現和中間件的熱點保護模塊并存
熱點發下要做到接近實時
3．處理熱點數據
（1）優化熱點數據
優化熱點數據最有效的方法就是緩存熱點數據，緩存數據可以用LRU淘汰算法替換。
（2）限制
根據商品id做一致性Hash，放入不同的隊列中，防止因某些商品占用太多的服務。
（3）隔離
將這種熱點數據隔離出來，不讓1%的請求影響到另外99%的請求。
隔離有以下幾個層次，業務隔離、系統隔離、數據隔離
六、流量削峰方案
1．排隊
把一步的操作變成兩步的操作，增加一步起到緩沖的作用。
2．答題
防止部分秒殺器作弊
延緩請求，請求量削峰
3．分層過濾
將動態請求的讀數據緩存在web端，過濾掉無效數據；
讀數據不做強一致校驗；
對寫數據進行基于時間的合理分片，過濾掉過期的失效請求；
對寫請求做限流保護，將超出系統承載能力的請求過濾掉；
對寫數據進行強一致校驗，只保留最后有效數據；
七、提高系統性能方案
1．影響性能的因素（服務器性能一般用QPS來衡量）
（1）一次響應的服務端耗時，對性能有影響的是CPU的執行時間
（2）處理請求的線程數，合理的并發線程數
八、減庫存設計核心邏輯
1．減庫存的3種方式，以及可能存在的問題
（1）下單減庫存，下單不付款（大型秒殺系統一般使用下單減庫存）
（2）付款減庫存，庫存超賣
（3）預扣庫存（下單后庫存保留一定時間）
2．秒殺減庫存的極致優化
（1）秒殺商品的減庫存邏輯非常單一，可以再緩存系統完成扣減
（2）比較復雜的庫存扣減邏輯，要在數據庫中完成扣減
九、備選方案的設計
1．高可用建設應該從哪里著手
（1）架構階段
主要考慮可擴展性和容錯性，避免出現單機
（2）編碼階段
主要考慮代碼的健壯性，涉及遠程調用要設置合理的超時退出
也要對調用的返回結果集有預期，防止返回的結果超出程序處理的范圍
（3）測試階段
保證測試用例的覆蓋度
保證最壞的情況發生時，有相應的處理流程
（4）發布階段
要有緊急的回滾機制
（5）運行階段
對系統的監控要準確及時
發現問題能準確報警，數據要準確詳細，以便排查問題
（6）故障發生
及時止損
及時恢復，并定位原因解決問題