秒殺特性：

1. 商品個數有限

2. 時間分布集中

3. 流量超級大

整體方案：

1. 產品策略

a. 分離核心流程與其他可以延后處理的流程

b. 針對異常情況進行文案引導

2. 技術策略

a. 客戶端、接入層、應用層、存儲層 各層整個鏈路梳理。任何一個環節異常，都可能導致整體服務不可用。

b. 客戶端重試策略的合理設計。固定超時時間+隨機時間長，遞增的超時時間，防止自我DDOS情況的發生。

c. 接入層是所有流量的入口，因此這里需要根據下游應用層處理能力，做好相應的限流。接入層可以使用 nginx, 性能有保障，配合 限流模塊 實現。 其中包括 粗細管道。

c1. 提前把符合條件的uid ，加入cache, 在接入層快速鑒權，過濾不符合條件的用戶。

c2. ip 頻次 限制，設備檢測，防止黑產，過濾無效用戶。

c3. 針對秒殺商品總數有限，每個接入點放入的有效請求數超過總數后，直接返回結果。

d. 在應用層分離核心流程，在秒殺時，先處理核心流程，非關鍵流程延后處理，同時支持失敗補償機制，以及相應的冪等重試。

e. 存儲層 緩存 redis 、消息隊列 kafka, 最終記錄寫入mysql

f. 針對秒殺商品的庫存，可以存入redis，更進一步可以再把這個總值提前拆分到N個節點上。

f1. 在redis中記錄是否領取成功，用于用戶實時查看結果。

g. 領取成功后，把對應的數據寫入消息隊列(kafka)，kafka的寫入性能在極限情況下，可以可以配置到非常高的，因此性能問題不必擔心。

h. 異步消費隊列數據，補齊之前的整個秒殺中未完成的邏輯。

3. 可用性

a. 靜態資源的cdn部署，動態服務分地區部署，加速整個服務的響應時間。

b. 接入層、應用層 、存儲層容災，都至少部署在2個IDC，標準的做法是 2地3中心，或者3地5中心。

c. 存儲層往往為了高性能，會選擇異步復制的策略，因此如果由于故障進行主備切換，可能會造成備庫數據不是最新的數據，造成超賣情況。如果要避免超賣，勢必需要等主備同步完成，這將犧牲服務可用性。需要根據業務場景權衡。

d. 監控系統，包括服務基礎監控，業務監控，秒殺數據的監控

e. 各種異常的預案，針對各種預案，提前寫好執行方案。隨時一鍵切換。

f. 秒殺相關的資源 與其他基礎產品資源隔離，避免影響主要產品使用。這里資源包括 域名、接入層、應用層、緩存、數據庫等資源。

4. 驗證

a. 全流程壓測。包括基本接口qps, 還要包括數據完整性驗證。

b. 破壞性驗證。比如斷掉其中一個機房的全部服務，或者斷掉集群中的任意節點。

c. 日志信息驗證。如果某個環節發生失敗，是否可以通過日志追蹤到數據，保證最終一致性。

d. 異常預案驗證。包括 切換的正確性驗證，以及恢復時長的驗證 。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的java信用分秒杀系统设计思路,秒杀系统设计思路的全部內容，希望文章能夠幫你解決所遇到的問題。

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