轉(zhuǎn)載
2016-04-06 58沈劍 架構(gòu)師之路
本文曾在“架構(gòu)師之路”上發(fā)布過(guò)据过，近期支援Qcon-AS大會(huì)崎页，在微信群里分享了該話題阁苞，故對(duì)原文進(jìn)行重新整理與發(fā)布困檩。
一、秒殺業(yè)務(wù)為什么難做
1）im系統(tǒng)那槽，例如qq或者微博悼沿，每個(gè)人都讀自己的數(shù)據(jù)（好友列表、群列表骚灸、個(gè)人信息）糟趾；
2）微博系統(tǒng)，每個(gè)人讀你關(guān)注的人的數(shù)據(jù)，一個(gè)人讀多個(gè)人的數(shù)據(jù)拉讯；
3）秒殺系統(tǒng)涤浇，庫(kù)存只有一份鳖藕，所有人會(huì)在集中的時(shí)間讀和寫這些數(shù)據(jù)魔慷，多個(gè)人讀一個(gè)數(shù)據(jù)。
例如：小米手機(jī)每周二的秒殺著恩，可能手機(jī)只有1萬(wàn)部院尔，但瞬時(shí)進(jìn)入的流量可能是幾百幾千萬(wàn)。
又例如：12306搶票喉誊，票是有限的邀摆，庫(kù)存一份，瞬時(shí)流量非常多伍茄，都讀相同的庫(kù)存栋盹。讀寫沖突，鎖非常嚴(yán)重敷矫，這是秒殺業(yè)務(wù)難的地方例获。那我們?cè)趺磧?yōu)化秒殺業(yè)務(wù)的架構(gòu)呢？
二曹仗、優(yōu)化方向
優(yōu)化方向有兩個(gè)（今天就講這兩個(gè)點(diǎn)）：
（1）將請(qǐng)求盡量攔截在系統(tǒng)上游（不要讓鎖沖突落到數(shù)據(jù)庫(kù)上去）榨汤。傳統(tǒng)秒殺系統(tǒng)之所以掛，請(qǐng)求都?jí)旱沽撕蠖藬?shù)據(jù)層怎茫，數(shù)據(jù)讀寫鎖沖突嚴(yán)重收壕，并發(fā)高響應(yīng)慢，幾乎所有請(qǐng)求都超時(shí)轨蛤，流量雖大蜜宪，下單成功的有效流量甚小。以12306為例祥山，一趟火車其實(shí)只有2000張票端壳，200w個(gè)人來(lái)買，基本沒有人能買成功枪蘑，請(qǐng)求有效率為0损谦。
（2）充分利用緩存，秒殺買票岳颇，這是一個(gè)典型的讀多些少的應(yīng)用場(chǎng)景照捡，大部分請(qǐng)求是車次查詢，票查詢话侧，下單和支付才是寫請(qǐng)求栗精。一趟火車其實(shí)只有2000張票，200w個(gè)人來(lái)買，最多2000個(gè)人下單成功悲立，其他人都是查詢庫(kù)存鹿寨，寫比例只有0.1%，讀比例占99.9%薪夕，非常適合使用緩存來(lái)優(yōu)化脚草。好，后續(xù)講講怎么個(gè)“將請(qǐng)求盡量攔截在系統(tǒng)上游”法原献，以及怎么個(gè)“緩存”法馏慨，講講細(xì)節(jié)。
三姑隅、常見秒殺架構(gòu)
常見的站點(diǎn)架構(gòu)基本是這樣的（絕對(duì)不畫忽悠類的架構(gòu)圖）
（1）瀏覽器端写隶，最上層，會(huì)執(zhí)行到一些JS代碼
（2）站點(diǎn)層讲仰，這一層會(huì)訪問(wèn)后端數(shù)據(jù)慕趴，拼html頁(yè)面返回給瀏覽器
（3）服務(wù)層，向上游屏蔽底層數(shù)據(jù)細(xì)節(jié)鄙陡，提供數(shù)據(jù)訪問(wèn)
（4）數(shù)據(jù)層冕房，最終的庫(kù)存是存在這里的，mysql是一個(gè)典型（當(dāng)然還有會(huì)緩存）
這個(gè)圖雖然簡(jiǎn)單柔吼，但能形象的說(shuō)明大流量高并發(fā)的秒殺業(yè)務(wù)架構(gòu)毒费，大家要記得這一張圖。
后面細(xì)細(xì)解析各個(gè)層級(jí)怎么優(yōu)化愈魏。
四觅玻、各層次優(yōu)化細(xì)節(jié)
第一層，客戶端怎么優(yōu)化（瀏覽器層培漏，APP****層）
問(wèn)大家一個(gè)問(wèn)題溪厘，大家都玩過(guò)微信的搖一搖搶紅包對(duì)吧，每次搖一搖牌柄，就會(huì)往后端發(fā)送請(qǐng)求么畸悬？回顧我們下單搶票的場(chǎng)景，點(diǎn)擊了“查詢”按鈕之后珊佣，系統(tǒng)那個(gè)卡呀蹋宦，進(jìn)度條漲的慢呀，作為用戶咒锻，我會(huì)不自覺的再去點(diǎn)擊“查詢”冷冗，對(duì)么？繼續(xù)點(diǎn)惑艇，繼續(xù)點(diǎn)蒿辙，點(diǎn)點(diǎn)點(diǎn)拇泛。。思灌。有用么俺叭？平白無(wú)故的增加了系統(tǒng)負(fù)載，一個(gè)用戶點(diǎn)5次泰偿，80%的請(qǐng)求是這么多出來(lái)的熄守，怎么整？
（a）產(chǎn)品層面甜奄，用戶點(diǎn)擊“查詢”或者“購(gòu)票”后柠横，按鈕置灰窃款，禁止用戶重復(fù)提交請(qǐng)求课兄；
（b）JS層面，限制用戶在x秒之內(nèi)只能提交一次請(qǐng)求晨继；
APP層面烟阐，可以做類似的事情，雖然你瘋狂的在搖微信紊扬，其實(shí)x秒才向后端發(fā)起一次請(qǐng)求蜒茄。這就是所謂的“將請(qǐng)求盡量攔截在系統(tǒng)上游”，越上游越好餐屎，瀏覽器層檀葛，APP層就給攔住，這樣就能擋住80%+的請(qǐng)求腹缩，這種辦法只能攔住普通用戶（但99%的用戶是普通用戶）對(duì)于群內(nèi)的高端程序員是攔不住的屿聋。firebug一抓包，http長(zhǎng)啥樣都知道藏鹊，js是萬(wàn)萬(wàn)攔不住程序員寫for循環(huán)润讥，調(diào)用http接口的，這部分請(qǐng)求怎么處理盘寡？
第二層楚殿，站點(diǎn)層面的請(qǐng)求攔截
怎么攔截？怎么防止程序員寫for循環(huán)調(diào)用竿痰，有去重依據(jù)么脆粥？ip？cookie-id影涉？…想復(fù)雜了变隔，這類業(yè)務(wù)都需要登錄，用uid即可常潮。在站點(diǎn)層面弟胀，對(duì)uid進(jìn)行請(qǐng)求計(jì)數(shù)和去重，甚至不需要統(tǒng)一存儲(chǔ)計(jì)數(shù)，直接站點(diǎn)層內(nèi)存存儲(chǔ)（這樣計(jì)數(shù)會(huì)不準(zhǔn)孵户，但最簡(jiǎn)單）萧朝。一個(gè)uid，5秒只準(zhǔn)透過(guò)1個(gè)請(qǐng)求夏哭，這樣又能攔住99%的for循環(huán)請(qǐng)求检柬。
5s只透過(guò)一個(gè)請(qǐng)求，其余的請(qǐng)求怎么辦竖配？緩存何址，頁(yè)面緩存，同一個(gè)uid进胯，限制訪問(wèn)頻度用爪，做頁(yè)面緩存，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求胁镐，均返回同一頁(yè)面偎血。同一個(gè)item的查詢，例如車次盯漂，做頁(yè)面緩存颇玷，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求，均返回同一頁(yè)面就缆。如此限流帖渠，既能保證用戶有良好的用戶體驗(yàn)（沒有返回404）又能保證系統(tǒng)的健壯性（利用頁(yè)面緩存，把請(qǐng)求攔截在站點(diǎn)層了）竭宰。
頁(yè)面緩存不一定要保證所有站點(diǎn)返回一致的頁(yè)面空郊，直接放在每個(gè)站點(diǎn)的內(nèi)存也是可以的。優(yōu)點(diǎn)是簡(jiǎn)單羞延，壞處是http請(qǐng)求落到不同的站點(diǎn)渣淳，返回的車票數(shù)據(jù)可能不一樣，這是站點(diǎn)層的請(qǐng)求攔截與緩存優(yōu)化伴箩。
好入愧，這個(gè)方式攔住了寫for循環(huán)發(fā)http請(qǐng)求的程序員，有些高端程序員（黑客）控制了10w個(gè)肉雞嗤谚，手里有10w個(gè)uid棺蛛，同時(shí)發(fā)請(qǐng)求（先不考慮實(shí)名制的問(wèn)題，小米搶手機(jī)不需要實(shí)名制）巩步，這下怎么辦旁赊，站點(diǎn)層按照uid限流攔不住了。
第三層 ****服務(wù)層來(lái)攔截（反正就是不要讓請(qǐng)求落到數(shù)據(jù)庫(kù)上去）
服務(wù)層怎么攔截椅野？大哥终畅，我是服務(wù)層籍胯，我清楚的知道小米只有1萬(wàn)部手機(jī)，我清楚的知道一列火車只有2000張車票离福，我透10w個(gè)請(qǐng)求去數(shù)據(jù)庫(kù)有什么意義呢杖狼？沒錯(cuò)，請(qǐng)求隊(duì)列妖爷！
對(duì)于寫請(qǐng)求蝶涩，做請(qǐng)求隊(duì)列，每次只透有限的寫請(qǐng)求去數(shù)據(jù)層（下訂單絮识，支付這樣的寫業(yè)務(wù)）
1w部手機(jī)绿聘，只透1w個(gè)下單請(qǐng)求去db
3k張火車票，只透3k個(gè)下單請(qǐng)求去db
如果均成功再放下一批次舌，如果庫(kù)存不夠則隊(duì)列里的寫請(qǐng)求全部返回“已售完”熄攘。
對(duì)于讀請(qǐng)求，怎么優(yōu)化垃它？cache抗鲜屏，不管是memcached還是redis烹看，單機(jī)抗個(gè)每秒10w應(yīng)該都是沒什么問(wèn)題的国拇。如此限流，只有非常少的寫請(qǐng)求惯殊，和非常少的讀緩存mis的請(qǐng)求會(huì)透到數(shù)據(jù)層去酱吝，又有99.9%的請(qǐng)求被攔住了。
當(dāng)然土思，還有業(yè)務(wù)規(guī)則上的一些優(yōu)化务热。回想12306所做的己儒，分時(shí)分段售票崎岂，原來(lái)統(tǒng)一10點(diǎn)賣票，現(xiàn)在8點(diǎn)闪湾，8點(diǎn)半冲甘，9點(diǎn)，...每隔半個(gè)小時(shí)放出一批：將流量攤勻途样。
其次江醇，數(shù)據(jù)粒度的優(yōu)化：你去購(gòu)票，對(duì)于余票查詢這個(gè)業(yè)務(wù)何暇，票剩了58張陶夜，還是26張，你真的關(guān)注么裆站，其實(shí)我們只關(guān)心有票和無(wú)票条辟？流量大的時(shí)候黔夭，做一個(gè)粗粒度的“有票”“無(wú)票”緩存即可。
第三羽嫡，一些業(yè)務(wù)邏輯的異步：例如下單業(yè)務(wù)與 支付業(yè)務(wù)的分離纠修。這些優(yōu)化都是結(jié)合業(yè)務(wù) 來(lái)的，我之前分享過(guò)一個(gè)觀點(diǎn)“一切脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓”架構(gòu)的優(yōu)化也要針對(duì)業(yè)務(wù)厂僧。
好了扣草，最后是數(shù)據(jù)庫(kù)層
瀏覽器攔截了80%，站點(diǎn)層攔截了99.9%并做了頁(yè)面緩存颜屠，服務(wù)層又做了寫請(qǐng)求隊(duì)列與數(shù)據(jù)緩存辰妙，每次透到數(shù)據(jù)庫(kù)層的請(qǐng)求都是可控的。db基本就沒什么壓力了甫窟，閑庭信步密浑，單機(jī)也能扛得住，還是那句話粗井，庫(kù)存是有限的尔破，小米的產(chǎn)能有限，透這么多請(qǐng)求來(lái)數(shù)據(jù)庫(kù)沒有意義浇衬。
全部透到數(shù)據(jù)庫(kù)懒构，100w個(gè)下單，0個(gè)成功耘擂，請(qǐng)求有效率0%胆剧。透3k個(gè)到數(shù)據(jù)，全部成功醉冤，請(qǐng)求有效率100%秩霍。
五、總結(jié)
上文應(yīng)該描述的非常清楚了蚁阳，沒什么總結(jié)了铃绒，對(duì)于秒殺系統(tǒng)，再次重復(fù)下我個(gè)人經(jīng)驗(yàn)的兩個(gè)架構(gòu)優(yōu)化思路：
（1）盡量將請(qǐng)求攔截在系統(tǒng)上游（越上游越好）螺捐；
（2）讀多寫少的常用多使用緩存（緩存抗讀壓力）颠悬；
瀏覽器和APP：做限速
站點(diǎn)層：按照uid做限速，做頁(yè)面緩存
服務(wù)層：按照業(yè)務(wù)做寫請(qǐng)求隊(duì)列控制流量归粉，做數(shù)據(jù)緩存
數(shù)據(jù)層：閑庭信步
并且：結(jié)合業(yè)務(wù)做優(yōu)化
六椿疗、Q&A
問(wèn)題1****、按你的架構(gòu)糠悼，其實(shí)壓力最大的反而是站點(diǎn)層届榄，假設(shè)真實(shí)有效的請(qǐng)求數(shù)有1000****萬(wàn)，不太可能限制請(qǐng)求連接數(shù)吧倔喂，那么這部分的壓力怎么處理铝条？
答：每秒鐘的并發(fā)可能沒有1kw靖苇，假設(shè)有1kw，解決方案2個(gè)：
（1）站點(diǎn)層是可以通過(guò)加機(jī)器擴(kuò)容的班缰，最不濟(jì)1k臺(tái)機(jī)器來(lái)唄贤壁。
（2）如果機(jī)器不夠，拋棄請(qǐng)求埠忘，拋棄50%（50%直接返回稍后再試）脾拆，原則是要保護(hù)系統(tǒng)，不能讓所有用戶都失敗莹妒。
問(wèn)題2****名船、“控制了10w****個(gè)肉雞，手里有10w****個(gè)uid****旨怠，同時(shí)發(fā)請(qǐng)求” ****這個(gè)問(wèn)題怎么解決哈渠驼？
答：上面說(shuō)了，服務(wù)層寫請(qǐng)求隊(duì)列控制
問(wèn)題3****：****限制訪問(wèn)頻次的緩存鉴腻，是否也可以用于搜索迷扇？例如A****用戶搜索了“手機(jī)”，B****用戶搜索“手機(jī)”爽哎，優(yōu)先使用A****搜索后生成的緩存頁(yè)面蜓席？
答：這個(gè)是可以的，這個(gè)方法也經(jīng)常用在“動(dòng)態(tài)”運(yùn)營(yíng)活動(dòng)頁(yè)倦青，例如短時(shí)間推送4kw用戶app-push運(yùn)營(yíng)活動(dòng)瓮床，做頁(yè)面緩存。
問(wèn)題4****：如果隊(duì)列處理失敗产镐，如何處理？肉雞把隊(duì)列被撐爆了怎么辦踢步？
答：處理失敗返回下單失敗癣亚，讓用戶再試。隊(duì)列成本很低获印，爆了很難吧述雾。最壞的情況下，緩存了若干請(qǐng)求之后兼丰，后續(xù)請(qǐng)求都直接返回“無(wú)票”（隊(duì)列里已經(jīng)有100w請(qǐng)求了玻孟，都等著，再接受請(qǐng)求也沒有意義了）
問(wèn)題5****：站點(diǎn)層過(guò)濾的話鳍征，是把uid****請(qǐng)求數(shù)單獨(dú)保存到各個(gè)站點(diǎn)的內(nèi)存中么黍翎？如果是這樣的話，怎么處理多臺(tái)服務(wù)器集群經(jīng)過(guò)負(fù)載均衡器將相同用戶的響應(yīng)分布到不同服務(wù)器的情況呢艳丛？還是說(shuō)將站點(diǎn)層的過(guò)濾放到負(fù)載均衡前匣掸？
答：可以放在內(nèi)存趟紊，這樣的話看似一臺(tái)服務(wù)器限制了5s一個(gè)請(qǐng)求，全局來(lái)說(shuō)（假設(shè)有10臺(tái)機(jī)器）碰酝，其實(shí)是限制了5s 10個(gè)請(qǐng)求霎匈，解決辦法：
1）加大限制（這是建議的方案，最簡(jiǎn)單）
2）在nginx層做7層均衡送爸，讓一個(gè)uid的請(qǐng)求盡量落到同一個(gè)機(jī)器上
問(wèn)題6****：服務(wù)層過(guò)濾的話铛嘱，隊(duì)列是服務(wù)層統(tǒng)一的一個(gè)隊(duì)列？還是每個(gè)提供服務(wù)的服務(wù)器各一個(gè)隊(duì)列？如果是統(tǒng)一的一個(gè)隊(duì)列的話，需不需要在各個(gè)服務(wù)器提交的請(qǐng)求入隊(duì)列前進(jìn)行鎖控制蛮瞄？
答：可以不用統(tǒng)一一個(gè)隊(duì)列夭谤，這樣的話每個(gè)服務(wù)透過(guò)更少量的請(qǐng)求（總票數(shù)/服務(wù)個(gè)數(shù)），這樣簡(jiǎn)單猛频。統(tǒng)一一個(gè)隊(duì)列又復(fù)雜了。
問(wèn)題7****：秒殺之后的支付完成，以及未支付取消占位蚓让，如何對(duì)剩余庫(kù)存做及時(shí)的控制更新****？
答：數(shù)據(jù)庫(kù)里一個(gè)狀態(tài)讥珍，未支付历极。如果超過(guò)時(shí)間，例如45分鐘衷佃，庫(kù)存會(huì)重新會(huì)恢復(fù)（大家熟知的“回倉(cāng)”）趟卸，給我們搶票的啟示是，開動(dòng)秒殺后氏义，45分鐘之后再試試看锄列，說(shuō)不定又有票喲~
問(wèn)題8****：不同的用戶****瀏覽同一個(gè)商品 ****落在不同的緩存實(shí)例****顯示的庫(kù)存完全不一樣****請(qǐng)問(wèn)老師怎么做緩存數(shù)據(jù)一致****或者是允許臟讀？
答：目前的架構(gòu)設(shè)計(jì)惯悠，請(qǐng)求落到不同的站點(diǎn)上邻邮，數(shù)據(jù)可能不一致（頁(yè)面緩存不一樣），這個(gè)業(yè)務(wù)場(chǎng)景能接受克婶。但數(shù)據(jù)庫(kù)層面真實(shí)數(shù)據(jù)是沒問(wèn)題的筒严。
問(wèn)題9****：就算處于業(yè)務(wù)把優(yōu)化考慮****“3k****張火車票，只透3k****個(gè)下單請(qǐng)求去db****”那這3K****個(gè)訂單就不會(huì)發(fā)生擁堵了嗎情萤？
答：（1）數(shù)據(jù)庫(kù)抗3k個(gè)寫請(qǐng)求還是ok的鸭蛙；（2）可以數(shù)據(jù)拆分；（3）如果3k扛不住筋岛，服務(wù)層可以控制透過(guò)去的并發(fā)數(shù)量娶视，根據(jù)壓測(cè)情況來(lái)吧，3k只是舉例泉蝌；
問(wèn)題10****歇万；如果在站點(diǎn)層或者服務(wù)層處理后臺(tái)失敗的話揩晴，需不需要考慮對(duì)這批處理失敗的請(qǐng)求做重放？還是就直接丟棄贪磺？
答：別重放了硫兰，返回用戶查詢失敗或者下單失敗吧，架構(gòu)設(shè)計(jì)原則之一是“fail fast”寒锚。
問(wèn)題11.****對(duì)于大型系統(tǒng)的秒殺劫映，比如12306****，同時(shí)進(jìn)行的秒殺活動(dòng)很多刹前，如何分流泳赋？
答：垂直拆分
問(wèn)題12****、額外又想到一個(gè)問(wèn)題喇喉。這套流程做成同步還是異步的祖今？如果是同步的話，應(yīng)該還存在會(huì)有響應(yīng)反饋慢的情況拣技。但如果是異步的話千诬，如何控制能夠?qū)㈨憫?yīng)結(jié)果返回正確的請(qǐng)求方？
答：用戶層面肯定是同步的（用戶的http請(qǐng)求是夯住的）膏斤，服務(wù)層面可以同步可以異步徐绑。
問(wèn)題13****、秒殺群提問(wèn)：減庫(kù)存是在那個(gè)階段減呢莫辨？如果是下單鎖庫(kù)存的話傲茄，大量惡意用戶下單鎖庫(kù)存而不支付如何處理呢？
答：數(shù)據(jù)庫(kù)層面寫請(qǐng)求量很低沮榜，還好盘榨，下單不支付，等時(shí)間過(guò)完再“回倉(cāng)”敞映，之前提過(guò)了较曼。
