高并發(fā)場景下秒殺系統(tǒng)的設(shè)計思路
點擊上方「藍字」關(guān)注我們
1. 概述
秒殺系統(tǒng)之所以難做，是因為在極短的時間內(nèi)涌入大量的請求，來同時訪問有限的服務(wù)資源，從而造成系統(tǒng)負(fù)載壓力大，甚至導(dǎo)致系統(tǒng)服務(wù)癱瘓以及宕機的可能。本文會介紹秒殺系統(tǒng)中存在的痛點以及針對這些點的優(yōu)化思路。
2. 秒殺系統(tǒng)是什么鬼
如：12306的春節(jié)搶票、各大電商搞的定時搶購活動，如小米手機的在線搶購等，搶過火車票的同學(xué)都知道在放票的那一瞬間可能1s都不到，票就被搶購一空了。
3. 秒殺系統(tǒng)的難點
（1）短時間內(nèi)高并發(fā)，系統(tǒng)負(fù)載壓力大
（2）競爭的資源有限，數(shù)據(jù)庫鎖沖突嚴(yán)重
（3）避免對其他業(yè)務(wù)的影響
4. 常見的互聯(lián)網(wǎng)分層架構(gòu)
（1）客戶端層：手機或PC端操作的客戶端頁面，域名通過DNS解析路由到NG
（2）反向代理層：一般通過NG作為反向代理，將客戶端請求均衡路由到后端站點服務(wù)，NG也可以水平擴展為多實例，且每個實例可單獨部署為主從的高可用方案。
（3）站點層：站點層可以水平擴展為多個實例部署，以此來均衡來自客戶端請求產(chǎn)生的高并發(fā)負(fù)載，多個web server之間的session信息可以集中存儲于分布式緩存服務(wù)（Redis，MemCache）中。
（4）服務(wù)層：服務(wù)層也可水平擴展為多個實例部署，即時下最火的微服務(wù)方式
（5）數(shù)據(jù)庫層：數(shù)據(jù)庫層的常見部署方式，如讀寫分離，分庫分表等
5. 秒殺系統(tǒng)的架構(gòu)原則
（1）盡量將請求攔截在上游
對于秒殺系統(tǒng)來說，系統(tǒng)的瓶頸一般在數(shù)據(jù)庫層，由于資源是有限的，如庫中共1萬張票，一瞬間并發(fā)進來100萬的請求，那么有99萬都是無用的請求，所以為了更好的保護底層有限的數(shù)據(jù)庫資源，盡量將請求攔截在上游。
（2）充分利用緩存
緩存不但極大的縮短了數(shù)據(jù)的訪問效率，更重要的是承載了底層數(shù)據(jù)庫的訪問壓力，所以對于讀多寫少的業(yè)務(wù)場景充分利用好緩存
（3）熱點隔離
業(yè)務(wù)隔離：如12306的分時段售票，將熱點數(shù)據(jù)分散處理，來降低系統(tǒng)負(fù)載壓力
系統(tǒng)隔離：實現(xiàn)系統(tǒng)的軟硬隔離，不光是實現(xiàn)軟件的隔離，還可以實現(xiàn)硬件的隔離，盡最大限度的減少秒殺帶來的高并發(fā)安全性問題。
數(shù)據(jù)隔離：啟用單獨的cache集群或數(shù)據(jù)庫來存放熱點數(shù)據(jù)
6. 優(yōu)化方案
（1）頁面端優(yōu)化，如：
按鈕置灰：禁止用戶重復(fù)提交請求
通過JS控制：在一定時間內(nèi)只能提交一次請求
（2）web server層優(yōu)化，如：
動靜分離：如將幾乎不變的靜態(tài)頁面直接通過NG或CDN來路由訪問，只有動態(tài)變換的頁面可以請求到web server端
頁面緩存化
Nginx反向代理實現(xiàn)web server端的水平擴展
（3）后端service服務(wù)層優(yōu)化
使用緩存（Redis、Memchched）：將讀多寫少的業(yè)務(wù)數(shù)據(jù)放入緩存，如秒殺業(yè)務(wù)中可以將更新頻繁的商品庫存信息放入Redis緩存處理
注：庫存信息放入Redis緩存的時候最好分為多份放入不同key的緩存中，如庫存為10萬可以分為10份分別放入不同key的緩存中，這樣將數(shù)據(jù)分散操作可以達到更高的讀寫性能。
使用隊列處理：將請求放入隊列排隊處理，以可控的速度來訪問底層DB
異步處理：如將秒殺成功的訂單通知信息通過消息隊列（RabbitMQ、Kafka）來異步處理
（4）DB層優(yōu)化
讀寫分離
分表分庫
數(shù)據(jù)庫集群
來源：https://my.oschina.net/feinik/blog/1807902
掃碼二維碼
獲取更多精彩
Java樂園
