秒殺系統難做，是因為庫存有限，很多人會在集中的時間內讀寫有限的數據，在短時間內，系統會面臨成千上萬倍的流量進入。那么如何能做好秒殺系統呢？我認為核心思想有這么兩點：
-
將請求盡量的在上游環節就攔截住（不要輕易到數據庫這一級）
-
充分利用緩存
那么這兩點如何實現呢，下面詳細說說：
-
最上層是客戶端層，常見的都是瀏覽器訪問。點擊一次【秒殺按鈕】，然后再點一次【秒殺按鈕】，那么是訪問了兩次后端系統么？如果用戶手速快一些的話，或者用第三方插件不停的點擊，那么豈不是多出來很多請求。從產品層面，我們會設置點擊一次按鈕后，將按鈕置灰，從技術角度，我們可以通過JS控制幾秒內只能提交一次請求。看，這就是“將請求盡量的在上游環節就攔截住”。
-
當然客戶端層做限制，對於在座的程序猿們都是小意思，因為一抓包，請求長什么樣子一清二楚，然后寫個腳本，循環調用就好了；為了防止這樣的情況發生，后端的服務需要做去重的工作。比如按照用戶名去重，在N秒內，只允許1個請求訪問進來，然后做頁面緩存；比如10秒內發送了一萬次請求，其中1次請求訪問成功並返回了頁面，將這個頁面進行緩存，剩余9999次請求直接返回這個緩存頁面。
-
再往下走，10秒內一個客戶只有一次請求進來，但是如果同時有一百萬個客戶，那么這10秒內也有有一百萬次訪問，那么如何應對呢？用【消息隊列】，所有的請求過來，都排隊吧，每次只讓有限的請求去訪問數據。
-
當然訪問數據也不是直接去讀寫數據庫，這里還有一層數據緩存，比如可以使用Memcached或者Redis緩存庫存剩余，通常在秒殺系統中，這個“庫存”可以是粗粒度的，也就是說這個數字可以是不准確的，客戶關心的是買到還是買不到，而不會關心剩余數量到底是20件還是10件；數據讀操作也可以放在緩存中，再由緩存和數據庫做數據同步。
-
上面幾步已經攔截了大多數的請求，到DB這一層的時候，基本上沒有什么壓力了。
秒殺是電商企業最吸引流量，也是最考驗技術的場景！
秒殺的系統設計其實遵循“倒金字塔”原理，就是從前端頁面，網絡，到后端服務，數據庫，一一的將請求濾掉，最終讓落在數據庫的數據都是滿足要求的有效數據，假設是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對同一個賬號進行限制；
④，數據庫系統： 使用讀寫分離 ，分庫分表 等手段提升數據庫系統的吞吐量！