秒殺系統設計方案
一、秒殺系統架構設計關鍵點
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）故障發生
及時止損
及時恢復，並定位原因解決問題