秒殺是電商企業最吸引流量，也是最考驗技術的場景！

秒殺的系統設計其實遵循“倒金字塔”原理，就是從前端頁面，網路，到後端服務，資料庫，一一的將請求濾掉，最終讓落在資料庫的資料都是滿足要求的有效資料，假設是100萬人參加1000臺機器的秒殺，即是設計100萬-->1000的過濾系統；

要達到這樣的目的通常有下列的手段:

②，控制網路流量暴增：將前端頁面放置在CDN節點，防止網路流量壓力快速增大；

閘道器進行限流：使用nginx 進行閘道器限流！

透過設定nginx引數limit_conn_zone ，limit_req_zone ，ngx_http_upstream_module進行限流！

1，如果沒有使用nginx限流，可使用spring-cloud-zuul進行閘道器限流！

2，非同步處理 ：防止同步呼叫帶來的阻塞，包括資料落庫等都可以使用非同步呼叫！

3，快取： 最重要的一步，可以事先將要秒殺的商品id進行快取，使用分散式鎖獲取到id和對應的userid進行繫結，才算秒殺成功，然後非同步儲存資料！

使用redis的watch對同一個賬號進行限制；

④，資料庫系統： 使用讀寫分離 ，分庫分表 等手段提升資料庫系統的吞吐量！

關於以上談到的技術，具體場景中可能會有更多的需求和問題出現，比如超賣超買等現象，需要具體分析，文章只提及整個系統的實現，筆者以後也會持續分享這種JAVA開發的技術和碰到的問題，敬請關注。。

秒殺系統難做，是因為庫存有限，很多人會在集中的時間內讀寫有限的資料，在短時間內，系統會面臨成千上萬倍的流量進入。那麼如何能做好秒殺系統呢？我認為核心思想有這麼兩點：

將請求儘量的在上游環節就攔截住（不要輕易到資料庫這一級）

充分利用快取

那麼這兩點如何實現呢，下面詳細說說：

最上層是客戶端層，常見的都是瀏覽器訪問。點選一次【秒殺按鈕】，然後再點一次【秒殺按鈕】，那麼是訪問了兩次後端系統麼？如果使用者手速快一些的話，或者用第三方外掛不停的點選，那麼豈不是多出來很多請求。從產品層面，我們會設定點選一次按鈕後，將按鈕置灰，從技術角度，我們可以透過JS控制幾秒內只能提交一次請求。看，這就是“將請求儘量的在上游環節就攔截住”。

當然客戶端層做限制，對於在座的程式猿們都是小意思，因為一抓包，請求長什麼樣子一清二楚，然後寫個指令碼，迴圈呼叫就好了；為了防止這樣的情況發生，後端的服務需要做去重的工作。比如按照使用者名稱去重，在N秒內，只允許1個請求訪問進來，然後做頁面快取；比如10秒內傳送了一萬次請求，其中1次請求訪問成功並返回了頁面，將這個頁面進行快取，剩餘9999次請求直接返回這個快取頁面。

再往下走，10秒內一個客戶只有一次請求進來，但是如果同時有一百萬個客戶，那麼這10秒內也有有一百萬次訪問，那麼如何應對呢？用【訊息佇列】，所有的請求過來，都排隊吧，每次只讓有限的請求去訪問資料。

當然訪問資料也不是直接去讀寫資料庫，這裡還有一層資料快取，比如可以使用Memcached或者Redis快取庫存剩餘，通常在秒殺系統中，這個“庫存”可以是粗粒度的，也就是說這個數字可以是不準確的，客戶關心的是買到還是買不到，而不會關心剩餘數量到底是20件還是10件；資料讀操作也可以放在快取中，再由快取和資料庫做資料同步。

上面幾步已經攔截了大多數的請求，到DB這一層的時候，基本上沒有什麼壓力了。

所謂秒殺，它的難點有兩個，分別是瞬時間的高併發與請求量遠大於庫存量，引申下來就是首先從伺服器的角度，要抗住這個瞬時間的巨大請求量，server不能被打崩潰；然後再在保證資料一致性的情況下，用好分散式鎖，進行秒殺請求分配。

首先，針對瞬時間的巨大請求量，這個問題的解決方式只有擴容。還記得每次出點新聞，微博的搜尋功能都會掛掉的事情嗎，那就是由於當時搜尋的人實在太多了，server實在沒法響應這麼多的請求，就掛了。微博的解決方式也就是擴容，當時王寶強和MR的事情，有一次好像是MR號稱要爆料，嚇得微博趕緊擴容，結果爆出來的料好像根本沒有水花。每次擴容都是要錢的啊，要花錢買機器部署伺服器的啊，才不是白白擴容的，所以那一次相當於微博被MR溜了一圈。等到上次陳羽凡吸毒，MR疑似在微博對映某人也吸毒的時候，微博的boss直接回復，“別鬧了，不會再為你擴容了”

那遠大於庫存量這個問題怎麼解決呢。其實也比較簡單，假如說現在有10個商品等待秒殺，但是此時有10000個請求，此時在持久層之上，可能是介面層，就會攔截掉99.9%的請求，也就是說，1000個請求裡，999個都在介面層就被處理掉，給了返回了，此時使用者看到的結果就是，秒殺失敗，沒有搶到。最後，1000個裡面剩下的最後一個幸運兒，才真正的走到了邏輯層，再去資料持久層裡拿到秒殺到的商品資訊。

所謂的秒殺就是營造商品熱銷.購買人數眾多.導致伺服器崩潰的效果...

當然是營造伺服器崩潰的假象...

可將秒殺連結單獨分流道一個低頻寬入口...

也可直接返回拒絕服務...

總之：

1.讓使用者感覺有很多人搶著買.買不到就虧了.

2.讓使用者買不到.買到了老闆就虧了..

....

****第二點尤其重要****

....

看看其他人的回答....

一地的技術直男....

活該搞一輩子技術...

你們連老闆要啥都不知道...

在那裡瞎研究...

方向不對.

你加多少班都是磨洋工...

1.前置攔截流量，活動內容，列表後臺生成報文結構放入cdn，靜態資源走cdn，客戶端判斷活動開始狀態，對活動狀態，庫存限制，使用者購買次數等限制利用openresty高效能節流

2.利用redis lua做事務，扣庫存，生成訂單。當然也可以預先生成訂單放入list中，搶兌時往外pop。兩種都可以防止超賣

3.提前生成驗證碼放入cdn，利用openresty生成隨機數，客戶端利用隨機數訪問cdn上圖片驗證碼。

4.非同步發mq搶兌記錄，防止薅羊毛，同時可以隨時後臺控制活動狀態，強制結束狀態，同時把庫存改為0

5.將uid和訂單關聯，利用redis setnx防止token被盜用，同時多個請求搶兌，生成異常的訂單和庫存。

6.做好限流。將次要業務用mq解耦同時消峰填谷。

7.使用多核cpu。設定好執行緒池。

以上在實際生產專案中考研。openresty介面8c16g單機可達到qps5w，響應時間200ms。

秒殺最主要做到90%流量都被客戶端快取，cdn，openresty攔截掉，剩下的10%流量是正常搶兌成功的，提高後端介面tps，同時不應該有請求進入資料庫，全部進去快取。對於庫存，訂單這些資料，非同步方式刷到資料庫中。