知識星球說起秒殺，從雙十一購物到春節搶紅包，再到逢年過節搶⻋票，“秒殺”的場景在我們的生活中處處可⻅。簡單來說，秒殺就是在同一個時刻有大量的請求，爭搶購買同一個商品並完成交易的過程。
不管校招，還是社招，如何設計一個秒殺系統的面試題經常出現，如果懂得其中原理，就可以對答如流，不過涉及到一些瓶頸最佳化，有些同學就未必都能答出。
面試官：簡單說一下秒殺系統的設計思路?
這種題目，小菜是準備過的，巴拉巴拉的說了一堆。
面試官：那這裡是怎麼保證秒殺成功的？
小菜：&8^%#
面試官：你這裡用了Redis，有什麼用？
小菜：#￥&……%
面試官：你用什麼測試過這個系統的併發量？
小菜：&*%$^&.
面試官：你覺得你這個系統還可以再最佳化麼？
小菜：&%……￥）
面試官：你知道這個系統的瓶頸在哪裡嗎？如果流量再大10倍，怎麼應對？
小菜：88！
秒殺系統的整體架構可以概括為“穩、準、快”。
穩
整個系統架構要滿足高可用，流量符合預期時肯定要穩定，超出預期時也同樣不能掉鏈子，你要保證秒殺活動順利完成，即秒殺商品順利地賣出去，這個是最基本的前提。
準
你的業務需求是秒殺10臺iPhone XS，那就只能成交10臺，多一臺少一臺都不行。一旦庫存不對，那平臺就要承擔損失。
快
就是說系統的效能要足夠高，否則你怎麼支撐這麼大的流量呢？不光是服務端要做極致的效能最佳化，而且在整個請求鏈路上都要做協同的最佳化，每個地方快一點，整個系統就完美了。
設計思路：將請求攔截在系統上游，降低下游壓力。在一個併發量大，實際需求小的系統中，應當儘量在前端攔截無效流量，降低下游伺服器和資料庫的壓力，不然很可能造成資料庫讀寫鎖衝突，甚至導致死鎖，最終請求超時。
限流：前端直接限流，允許少部分流量流向後端。
削峰：瞬時大流量峰值容易壓垮系統，解決這個問題是重中之重。常用的消峰方法有非同步處理、快取和訊息中介軟體等技術。
非同步處理：秒殺系統是一個高併發系統，採用非同步處理樣式可以極大地提高系統併發量，其實非同步處理就是削峰的一種實現方式。
記憶體快取：秒殺系統最大的瓶頸一般都是資料庫讀寫，由於資料庫讀寫屬於磁碟IO，效能很低，如果能夠把部分資料或業務邏輯轉移到記憶體快取，效率會有極大地提升。
訊息佇列：訊息佇列可以削峰，將攔截大量併發請求，這也是一個非同步處理過程，後臺業務根據自己的處理能力，從訊息佇列中主動的拉取請求訊息進行業務處理。
可拓展：當然如果我們想支援更多使用者，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了，像淘寶、京東等雙十一活動時會臨時增加大量機器應對交易高峰。
最後，更多關於秒殺系統的解決方案，推薦一個專欄.
-
如何才能做好動靜分離？有哪些方案可選？
-
如何理解QPS、響應時間和執行緒數之間的關係？
-
如何有針對性地處理好系統的“熱點資料”？
-
秒殺減庫存的方案應該如何設計？
專欄只要九塊九，
9.9 買不了吃虧（吃虧就殺死佔小狼）
9.9 買不了上當（上當就殺死佔小狼）
9.9 就可以帶回家（把佔小狼帶回家）
