鏈接：https://youzhixueyuan.com/how-to-design-double-11-seconds-kill-system.html
秒殺活動場景
淘寶雙11秒殺場景鸭丛，大量的用戶短時間內涌入特咆，瞬間流量巨大（高并發(fā)）渔隶，比如：1000萬人同一時間搶購100件商品怠肋。秒殺活動是一個特別考驗后臺數據庫、緩存服務的業(yè)務串慰，對于數據庫偏塞、緩存的性能要求特別嚴格。
秒殺背后的技術挑戰(zhàn)
1邦鲫、突增的服務器及網絡需求
通常情況下灸叼，雙 11 的服務器使用是平時的 3-5 倍，網絡帶寬是平時 N倍庆捺。
2古今、業(yè)務高并發(fā)，服務負載重
我們通常衡量一個 Web 系統(tǒng)的吞吐率的指標是 QPS（Query Per Second滔以，每秒處理請求數）捉腥，解決每秒數萬次的高并發(fā)場景，這個指標非常關鍵你画。
假設處理一個業(yè)務請求平均響應時間為 100 ms抵碟，同時，系統(tǒng)內有 20 臺 Web 服務器坏匪，配置最大連接數為 500 個拟逮，Web 系統(tǒng)的理論峰值 QPS 為（理想化的計算方式）：100000 （10萬QPS）意味著1 秒鐘可以處理完 10 萬的請求，而“秒殺”的那 5w/s 的秒殺似乎是“紙老虎”适滓。
實際情況敦迄，在高并發(fā)的實際場景下，服務器處于高負載的狀態(tài)凭迹，網絡帶寬被擠滿颅崩，在這個時候平均響應時間會被大大增加。隨著用戶數量的增加蕊苗，數據庫連接進程增加沿后，需要處理的上下文切換也越多，服務器造成負載壓力越來越重朽砰。
3尖滚、業(yè)務耦合度高，引起系統(tǒng)“雪崩”
更可怕的問題是瞧柔，當系統(tǒng)上某個應用因為延遲而變得不可用漆弄，用戶的點擊越頻繁，惡性循環(huán)最終導致“雪崩”造锅，因為其中一臺服務器掛了撼唾，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛哥蔚，然后惡性循環(huán)倒谷，將整個系統(tǒng)拖垮蛛蒙。
如何解決秒殺技術瓶頸
秒殺架構設計思路：
將請求攔截在系統(tǒng)上游，降低下游壓力：秒殺系統(tǒng)特點是并發(fā)量極大渤愁，但實際秒殺成功的請求數量卻很少牵祟，所以如果不在前端攔截很可能造成數據庫讀寫鎖沖突，甚至導致死鎖抖格，最終請求超時诺苹。
充分利用緩存(redis)：利用緩存可極大提高系統(tǒng)讀寫速度。
消息中間件(ActiveMQ雹拄、Kafka等)：消息隊列可以削峰收奔，將攔截大量并發(fā)請求，這也是一個異步處理過程滓玖，后臺業(yè)務根據自己的處理能力坪哄，從消息隊列中主動的拉取請求消息進行業(yè)務處理。
前端設計方案
?頁面靜態(tài)化：將活動頁面上的所有可以靜態(tài)的元素全部靜態(tài)化呢撞，并盡量減少動態(tài)元素损姜。通過CDN來抗峰值。
?禁止重復提交：用戶提交之后按鈕置灰殊霞，禁止重復提交
?用戶限流：在某一時間段內只允許用戶提交一次請求摧阅，比如可以采取IP限流
后端設計方案
?服務端控制器層(網關層)
?限制uid（UserID）訪問頻率：我們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它插件绷蹲，在服務端控制層需要針對同一個訪問uid棒卷，限制訪問頻率。
?服務層
上面只攔截了一部分訪問請求祝钢，當秒殺的用戶量很大時比规，即使每個用戶只有一個請求，到服務層的請求數量還是很大拦英。比如我們有100W用戶同時搶100臺手機蜒什，服務層并發(fā)請求壓力至少為100W。
?采用消息隊列緩存請求：既然服務層知道庫存只有100臺手機疤估，那完全沒有必要把100W個請求都傳遞到數據庫啊灾常，那么可以先把這些請求都寫到消息隊列緩存一下，數據庫層訂閱消息減庫存铃拇，減庫存成功的請求返回秒殺成功钞瀑，失敗的返回秒殺結束。
?利用緩存應對讀請求：比如雙11秒殺搶購慷荔，是典型的讀多寫少業(yè)務雕什，大部分請求是查詢請求，所以可以利用緩存分擔數據庫壓力。
?利用緩存應對寫請求：緩存也是可以應對寫請求的贷岸，比如我們就可以把數據庫中的庫存數據轉移到Redis緩存中壹士，所有減庫存操作都在Redis中進行，然后再通過后臺進程把Redis中的用戶秒殺請求同步到數據庫中凰盔。
數據庫層
數據庫層是最脆弱的一層墓卦，一般在應用設計時在上游就需要把請求攔截掉倦春，數據庫層只承擔“能力范圍內”的訪問請求户敬。所以，上面通過在服務層引入隊列和緩存睁本，讓最底層的數據庫高枕無憂尿庐。
比如：利用消息中間件和緩存實現(xiàn)簡單的秒殺系統(tǒng)
Redis是一個分布式緩存系統(tǒng)，支持多種數據結構呢堰，我們可以利用Redis輕松實現(xiàn)一個強大的秒殺系統(tǒng)抄瑟。
我們可以采用Redis 最簡單的key-value數據結構，用一個原子類型的變量值(AtomicInteger)作為key枉疼，把用戶id作為value皮假，庫存數量便是原子變量的最大值。對于每個用戶的秒殺骂维，我們使用 RPUSH key value插入秒殺請求惹资， 當插入的秒殺請求數達到上限時，停止所有后續(xù)插入航闺。
然后我們可以在臺啟動多個工作線程褪测，使用 LPOP key 讀取秒殺成功者的用戶id，然后再操作數據庫做最終的下訂單減庫存操作潦刃。
當然侮措，上面Redis也可以替換成消息中間件如ActiveMQ、Kafka等乖杠，也可以將緩存和消息中間件 組合起來分扎，緩存系統(tǒng)負責接收記錄用戶請求，消息中間件負責將緩存中的請求同步到數據庫胧洒。
秒殺架構設計總結：
限流： 鑒于只有少部分用戶能夠秒殺成功畏吓，所以要限制大部分流量，只允許少部分流量進入服務后端略荡。
削峰：對于秒殺系統(tǒng)瞬時會有大量用戶涌入庵佣，所以在搶購一開始會有很高的瞬間峰值。高峰值流量是壓垮系統(tǒng)很重要的原因汛兜，所以如何把瞬間的高流量變成一段時間平穩(wěn)的流量也是設計秒殺系統(tǒng)很重要的思路巴粪。實現(xiàn)削峰的常用的方法有利用緩存和消息中間件等技術。
異步處理：秒殺系統(tǒng)是一個高并發(fā)系統(tǒng)，采用異步處理模式可以極大地提高系統(tǒng)并發(fā)量肛根，其實異步處理就是削峰的一種實現(xiàn)方式辫塌。
內存緩存：秒殺系統(tǒng)最大的瓶頸一般都是數據庫讀寫，由于數據庫讀寫屬于磁盤IO派哲，性能很低臼氨，如果能夠把部分數據或業(yè)務邏輯轉移到內存緩存，效率會有極大地提升芭届。
可拓展：當然如果我們想支持更多用戶储矩，更大的并發(fā)，最好就將系統(tǒng)設計成彈性可拓展的褂乍，如果流量來了持隧，拓展機器就好了。像淘寶逃片、京東等雙十一活動時會增加大量機器應對交易高峰屡拨。
