高併發場景下秒殺系統的設計思路

1 概述

秒殺系統之因此難作，是由於在極短的時間內涌入大量的請求，來同時訪問有限的服務資源，從而形成系統負載壓力大，甚至致使系統服務癱瘓以及宕機的可能。本文會介紹秒殺系統中存在的痛點以及針對這些點的優化思路。

2 秒殺系統是什麼鬼

如：12306的春節搶票、各大電商搞的定時搶購活動，如小米手機的在線搶購等，搶過火車票的同窗都知道在放票的那一瞬間可能1s都不到，票就被搶購一空了。

3 秒殺系統的難點

（1）短期內高併發，系統負載壓力大

（2）競爭的資源有限，數據庫鎖衝突嚴重

（3）避免對其餘業務的影響

4 常見的互聯網分層架構

（1）客戶端層：手機或PC端操做的客戶端頁面，域名經過DNS解析路由到NG

（2）反向代理層：通常經過NG做爲反向代理，將客戶端請求均衡路由到後端站點服務，NG也能夠水平擴展爲多實例，且每一個實例可單獨部署爲主從的高可用方案。

（3）站點層：站點層能夠水平擴展爲多個實例部署，以此來均衡來自客戶端請求產生的高併發負載，多個web server之間的session信息能夠集中存儲於分佈式緩存服務（Redis，MemCache）中。

（4）服務層：服務層也可水平擴展爲多個實例部署，即時下最火的微服務方式

（5）數據庫層：數據庫層的常見部署方式，如讀寫分離，分庫分表等

5 秒殺系統的架構原則

（1）儘可能將請求攔截在上游

對於秒殺系統來講，系統的瓶頸通常在數據庫層，因爲資源是有限的，如庫中共1萬張票，一瞬間併發進來100萬的請求，那麼有99萬都是無用的請求，因此爲了更好的保護底層有限的數據庫資源，儘可能將請求攔截在上游。

（2）充分利用緩存

緩存不但極大的縮短了數據的訪問效率，更重要的是承載了底層數據庫的訪問壓力，因此對於讀多寫少的業務場景充分利用好緩存

（3）熱點隔離

業務隔離：如12306的分時段售票，將熱點數據分散處理，來下降系統負載壓力

系統隔離：實現系統的軟硬隔離，不光是實現軟件的隔離，還能夠實現硬件的隔離，盡最大限度的減小秒殺帶來的高併發安全性問題。

數據隔離：啓用單獨的cache集羣或數據庫來存放熱點數據

6 優化方案

（1）頁面端優化，如：

• 按鈕置灰：禁止用戶重複提交請求
• 經過JS控制：在必定時間內只能提交一次請求

（2）web server層優化，如：

• 動靜分離：如將幾乎不變的靜態頁面直接經過NG或CDN來路由訪問，只有動態變換的頁面能夠請求到web server端
• 頁面緩存化
• Nginx反向代理實現web server端的水平擴展

（3）後端service服務層優化

• 使用緩存（Redis、Memchched）：將讀多寫少的業務數據放入緩存，如秒殺業務中能夠將更新頻繁的商品庫存信息放入Redis緩存處理

注：庫存信息放入Redis緩存的時候最好分爲多份放入不一樣key的緩存中，如庫存爲10萬能夠分爲10份分別放入不一樣key的緩存中，這樣將數據分散操做能夠達到更高的讀寫性能。

• 使用隊列處理：將請求放入隊列排隊處理，以可控的速度來訪問底層DB
• 異步處理：如將秒殺成功的訂單通知信息經過消息隊列（RabbitMQ、Kafka）來異步處理

（4）DB層優化

• 讀寫分離
• 分表分庫
• 數據庫集羣