秒殺特性：

1. 商品個數(shù)有限

2. 時間分布集中

3. 流量超級大

整體方案：

1. 產(chǎn)品策略

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

b. 針對異常情況進(jìn)行文案引導(dǎo)

2. 技術(shù)策略

a. 客戶端、接入層、應(yīng)用層、存儲層 各層整個鏈路梳理。任何一個環(huán)節(jié)異常，都可能導(dǎo)致整體服務(wù)不可用。

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

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

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

c2. ip 頻次 限制，設(shè)備檢測，防止黑產(chǎn)，過濾無效用戶。

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

d. 在應(yīng)用層分離核心流程，在秒殺時，先處理核心流程，非關(guān)鍵流程延后處理，同時支持失敗補(bǔ)償機(jī)制，以及相應(yīng)的冪等重試。

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

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

f1. 在redis中記錄是否領(lǐng)取成功，用于用戶實時查看結(jié)果。

g. 領(lǐng)取成功后，把對應(yīng)的數(shù)據(jù)寫入消息隊列(kafka)，kafka的寫入性能在極限情況下，可以可以配置到非常高的，因此性能問題不必?fù)?dān)心。

h. 異步消費(fèi)隊列數(shù)據(jù)，補(bǔ)齊之前的整個秒殺中未完成的邏輯。

3. 可用性

a. 靜態(tài)資源的cdn部署，動態(tài)服務(wù)分地區(qū)部署，加速整個服務(wù)的響應(yīng)時間。

b. 接入層、應(yīng)用層 、存儲層容災(zāi)，都至少部署在2個IDC，標(biāo)準(zhǔn)的做法是 2地3中心，或者3地5中心。

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

d. 監(jiān)控系統(tǒng)，包括服務(wù)基礎(chǔ)監(jiān)控，業(yè)務(wù)監(jiān)控，秒殺數(shù)據(jù)的監(jiān)控

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

f. 秒殺相關(guān)的資源 與其他基礎(chǔ)產(chǎn)品資源隔離，避免影響主要產(chǎn)品使用。這里資源包括 域名、接入層、應(yīng)用層、緩存、數(shù)據(jù)庫等資源。

4. 驗證

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

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

c. 日志信息驗證。如果某個環(huán)節(jié)發(fā)生失敗，是否可以通過日志追蹤到數(shù)據(jù)，保證最終一致性。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。