秒殺系統優化思路

一、秒殺業務為什麼這麼難做

秒殺系統，庫存只有乙份，所有人會在集中的時間讀和寫這些資料。

例如：那我們怎麼優化秒殺業務呢？

二、優化方向

（以上的兩個場景要優化有兩個方向）

三、常見秒殺架構

常見的秒殺架構基本是這樣的

四、各層優化細節

回顧一下我們12306剛出來那年搶票的場景，點選「查詢」按鈕之後，系統卡在那裡或者響應非常慢，這時使用者就會再次點選」查詢「，繼續點點點，可是這樣有用麼？徙增系統負載，如果真實購買使用者只有200w，那乙個使用者多點選5次，

就有1000萬，多出來80%的使用者怎麼整？

上面說到搖紅包，就算我們瘋狂的把手機甩飛了，系統也只是在x秒才向系統傳送請求。

但是，這種辦法只能攔截住普通的使用者，對於高階的程式猿們來說是攔不住的，firebug一抓包，http長啥樣都知道了，js是攔不住程式設計師寫for迴圈呼叫http介面的，這部分請求如何處理？

怎麼防止程式猿們for迴圈請求呢？有去重依據麼？ip？cookie-id？這類「秒殺」業務都需要登入，用我們加了密的uid即可。在站點層面，對uid進行請求計數和去重，乙個uid在5秒內只允許1個請求（例如生成uid時加入時間戳），

這樣就可以攔截住程式猿們的for迴圈請求。

5秒只透過乙個請求，那其他請求怎麼辦？快取，頁面快取，同乙個uid訪問頻度做頁面快取，x秒內到達站點請求，均返回同乙個頁面。如此限流，既能保證使用者體驗又能保證系統的健壯性。

（頁面快取不一定要保證所有站點返回一致的頁面，直接放在每個站點的記憶體也可以，優點是簡單。缺點是http請求落到不同的站點，返回的車票資料可能不一樣。）

這是站點層請求攔截和快取的優化

如果，有黑客控制了10萬個肉雞，不同的uid，同時傳送請求的話，我們怎麼辦？站點層按照uid限流已經攔截不住了。

（反正不要讓請求落到資料層上）

服務層如何來攔截呢？請求佇列，對於寫入操作的請求，每次只透有限的請求去資料層，這個有限取決於有多少部小公尺手機或多少張火車票。如果庫存不夠則全部返回「已售完」。

對於讀取的請求如何優化？用cache抗，不管是mecached還是redis，單機抗個每秒10萬都沒問題，如此限流，只有非常少的寫入請求，和非常少的讀取快取mis的請求會透到資料層去，又有99.9%的請求被攔住了。

瀏覽器攔截了80%，站點層攔截了99.9%並做了頁面快取，服務層又做了請求佇列與資料快取，每次透到資料層的請求都是可控的。db基本沒什麼壓力了，還是那句話，庫存是有限的，透這麼多請求來資料庫沒有意義。

全部透到資料庫，100萬個下單，0個成功，透3000到資料庫，全部成功。請求有效率為100%。

總結：

再重複一下關於秒殺系統的兩個優化思路：

非常感謝。

如果對您有幫助，請點贊！