一、第一代秒殺價構

在電商模組直接插入秒殺系統，MYSQL

 

核心邏輯（通過資料庫updata 完成）

假設可以秒殺5臺：

“updata tbl set count = count+1 where id =101 and count+1 <= 5”

但資料庫太慢。

 

核心邏輯優化：

begin;

如果使用者無法即可獲得鎖，則返回錯誤。從而這個事物回滾。

select 1 from tbl where id=pk updata nowait;

updata tbl set count = count+1 where id =101 and count+1 <= 5

end;

效能可以提高60倍。

及時這樣網站還是崩潰了。量太大資料庫撐不住。

 

問題分析：

同步處理：對每個客戶請求都實時的去處理

資源耦合：秒殺系統和其他系統在一個模組裡面，當秒殺系統佔完資源其他系統資源也不夠用。

 

二、第二代秒殺系統

1、資源隔離

2、日誌做了非同步處理

 

核心邏輯：

每臺機器人工分配資格限額

每發一個資格，列印一條日誌

收集日誌，進行彙總

如果資格發光了，在對應的機器生成一個檔案

放號控制系統放號時如果發現存在檔案，則變為售完狀態

 

流程圖：

遇到的問題：

日誌丟失：在日誌收集模組

收集延遲

超賣：日誌丟失和收集延遲會導致超賣

隨著量大了會出現超賣問題。

 

核心邏輯優化：

日誌收集改為寫入redis裡面

遇到的問題：

效能問題：cpu100%，用的是非編譯語言寫的。

延遲：分鐘級

維持成本：擴容代價大，因為人工為每臺機器分配資格

量為每秒處理10萬的處理。

總結：

公平、排隊、保護後端

 

三、第三代秒殺系統大改變

1、goleng重構

2、通用產品

3、平臺全新架構、全面自動化

 

模組劃分：

長連線模組：用了保持使用者的連結，用了排隊和限流

放號模組：根據策略使用者能不能拿到資格（惡略使用者，如機器人）

 

架構設計一

MQ：redis

GO+REDIS

 

核心流程一

關鍵技術：

token的偽造

單Ridis抗不住

機器人算單

 

Token偽造解決方案：

token組成：uid+time+商品id+source+salt

摘要生成：md5(uid+time+商品id+source+salt)

伺服器重新計算摘要

和使用者傳過來的摘要進行對比

redis持久化儲存，避免碰撞

 

效能問題：

惡意使用者刷單：

黑名單

白名單

 

核心流程二

 

架構設計二

 

單這架構模式存在著時效效能差的問題。因為通過日誌收集來做，當量很大的時候，日誌列印的非常大，收集的話就會有延遲。

 

架構設計三

有運維問題

 

架構設計四

又崩潰了：

瞬時上百萬請求

redis嚴重堆積

放號模組處理不來

 

問題處理

過載保護：限流和主動拒絕

長連線模組限流，來保護放號模組；放號模組對時間過久的請求拒絕處理。

 

架構設計五

長連線模組拿到的請求加上當前時間，放號模組拿到請求判斷時間是否過期（設計過期時間）

 

核心流程三

這樣就設計出了一個性能穩定，併發量大的秒殺系統。