feed與秒殺,撐住10Wqps,架構(gòu)方案一樣嗎?
《??并發(fā)扣款,如何保證一致性????》一文,描述了高并發(fā)情況下,并發(fā)扣款的一致性,冪等性,以及ABA問(wèn)題。
很有朋友有疑問(wèn):如果存在一個(gè)大客戶(hù),這一個(gè)客戶(hù)并發(fā)量就非常高,版本號(hào)比對(duì)會(huì)導(dǎo)致大量的更新失敗。于是推出,這個(gè)方案不適用于高并發(fā)場(chǎng)景。
究竟是不是這樣呢?大家對(duì)高并發(fā)是不是有什么誤解呢?
?我經(jīng)常說(shuō),任何脫離業(yè)務(wù)場(chǎng)景的架構(gòu)設(shè)計(jì)都是耍流氓,今天來(lái)聊一聊三個(gè)高并發(fā)業(yè)務(wù)場(chǎng)景的架構(gòu)設(shè)計(jì)差異。?
一、QQ?
QQ的一些核心業(yè)務(wù)有:
- 個(gè)人:user(uid, user_info, …)
- 好友:user_friends(uid, friend_id, …)?
- 加入的群:user_groups(uid, group_id, …)?
- 群:group(gid, group_info, …)?
- 群成員:group_members(gid, uid, …)?
- 個(gè)人消息:msgs_user(msg_id, uid, …)?
- 群消息:msgs_group(msg_id, gid, …)?
這些信息的讀寫(xiě)有一個(gè)特點(diǎn),都會(huì)帶上uid/gid/msgid屬性。
例如,拉取好友列表:
在用戶(hù)量很大,并發(fā)量很大時(shí),不同用戶(hù)/群/消息數(shù)據(jù)的讀寫(xiě)并沒(méi)有鎖沖突。
畫(huà)外音:10W個(gè)用戶(hù)同時(shí)讀寫(xiě),彼此沒(méi)有鎖沖突。?
只有當(dāng),同一個(gè)用戶(hù),很短的時(shí)間內(nèi),有大量并發(fā)時(shí),才可能存在鎖沖突。
畫(huà)外音:例如,1個(gè)用戶(hù),1秒鐘讀寫(xiě)1W次。?
這類(lèi)場(chǎng)景下,使用《??并發(fā)扣款,如何保證一致性????》中的CAS樂(lè)觀來(lái)解決同一個(gè)用戶(hù)的并發(fā)沖突一致性,是絕對(duì)沒(méi)有問(wèn)題的。
二、微博?
微博的核心業(yè)務(wù)是feed流:
- ?發(fā)消息,寫(xiě)操作
- ?刷消息,讀操作
微博業(yè)務(wù)顯然是讀多寫(xiě)少的,在用戶(hù)刷消息時(shí),自己feed流里的消息,是由別人發(fā)出的。
查看自己主頁(yè)feed流,最樸素的實(shí)現(xiàn)方法是:
- 拉取自己關(guān)注的用戶(hù)id_list;
- 拉取這些用戶(hù)最近N條消息;
- 將這N*id_list條消息排序;
- 返回第一頁(yè)消息,得到自己主頁(yè)feed流;
在用戶(hù)量很大,并發(fā)量很大時(shí),會(huì)有一定數(shù)據(jù)的讀寫(xiě)鎖沖突。
畫(huà)外音:不像QQ,基本是讀寫(xiě)自己的數(shù)據(jù),微博要寫(xiě)自己的數(shù)據(jù),讀別人的數(shù)據(jù)。?
這類(lèi)場(chǎng)景下,《讀擴(kuò)散,寫(xiě)擴(kuò)散,終于講清楚了!》中提到的讀擴(kuò)散,寫(xiě)擴(kuò)散,也是常見(jiàn)的解決方案。
三、12306?
12306的核心業(yè)務(wù)是:
- ?查票,讀操作
- ?買(mǎi)票,寫(xiě)操作
在用戶(hù)量很大,并發(fā)量很大時(shí),有極大的鎖沖突。
畫(huà)外音:這個(gè)業(yè)務(wù),數(shù)據(jù)量并不大。?
這類(lèi)“秒殺”業(yè)務(wù),如果不做特殊的優(yōu)化,數(shù)據(jù)庫(kù)很容易死鎖卡死,沒(méi)有任何人能買(mǎi)票成功。
這類(lèi)“秒殺”業(yè)務(wù),有什么常見(jiàn)的優(yōu)化手段呢?
一般來(lái)說(shuō),系統(tǒng)上和業(yè)務(wù)上分別需要配合優(yōu)化。
系統(tǒng)層面,秒殺業(yè)務(wù)的優(yōu)化方向如何?
主要有兩項(xiàng):
(1) 將請(qǐng)求盡量攔截在系統(tǒng)上游,而不要讓鎖沖突落到數(shù)據(jù)庫(kù)。
傳統(tǒng)秒殺系統(tǒng)之所以掛,是因?yàn)檎?qǐng)求都?jí)旱搅撕蠖藬?shù)據(jù)層,數(shù)據(jù)讀寫(xiě)鎖沖突嚴(yán)重,并發(fā)高響應(yīng)慢,幾乎所有請(qǐng)求都超時(shí),訪問(wèn)流量大,下單成功的有效流量小。
一趟火車(chē)2000張票,200w個(gè)人同時(shí)來(lái)買(mǎi),沒(méi)有人能買(mǎi)成功,請(qǐng)求有效率為0。
畫(huà)外音:此時(shí)系統(tǒng)的效率,還不如線下售票窗口。
(2) 充分利用緩存。
秒殺買(mǎi)票,這是一個(gè)典型的讀多寫(xiě)少的業(yè)務(wù)場(chǎng)景:
- 車(chē)次查詢(xún),讀,量大
- 余票查詢(xún),讀,量大
- 下單和支付,寫(xiě),量小
一趟火車(chē)2000張票,200w個(gè)人同時(shí)來(lái)買(mǎi),最多2000個(gè)人下單成功,其他人都是查詢(xún)庫(kù)存,寫(xiě)比例只有0.1%,讀比例占99.9%,非常適合使用緩存來(lái)優(yōu)化。
秒殺業(yè)務(wù),常見(jiàn)的系統(tǒng)分層架構(gòu)如何?
秒殺業(yè)務(wù),可以使用典型的服務(wù)化分層架構(gòu):
- 端(瀏覽器/APP),最上層,面向用戶(hù)
- 站點(diǎn)層,訪問(wèn)后端數(shù)據(jù),拼裝html/json返回
- 服務(wù)層,屏蔽底層數(shù)據(jù)細(xì)節(jié),提供數(shù)據(jù)訪問(wèn)
- 數(shù)據(jù)層,DB存儲(chǔ)庫(kù)存,當(dāng)然也有緩存
這四層分別應(yīng)該如何優(yōu)化呢?
(1) 端上的請(qǐng)求攔截(瀏覽器/APP)
想必春節(jié)大家都玩過(guò)微信的搖一搖搶紅包,用戶(hù)每搖一次,真的就會(huì)往后端發(fā)送一次請(qǐng)求么?
回顧搶票的場(chǎng)景,用戶(hù)點(diǎn)擊“查詢(xún)”按鈕之后,系統(tǒng)卡頓,用戶(hù)著急,會(huì)不自覺(jué)的再去頻繁點(diǎn)擊“查詢(xún)”,不但沒(méi)用,反而平白無(wú)故增加系統(tǒng)負(fù)載,平均一個(gè)用戶(hù)點(diǎn)5次,80%的請(qǐng)求是這么多出來(lái)的。
JS層面,可以限制用戶(hù)在x秒之內(nèi)只能提交一次請(qǐng)求,從而降低系統(tǒng)負(fù)載。
畫(huà)外音:頻繁提交,可以友好提示“頻率過(guò)快”。
APP層面,可以做類(lèi)似的事情,雖然用戶(hù)瘋狂的在搖微信搶紅包,但其實(shí)x秒才向后端發(fā)起一次請(qǐng)求。
?畫(huà)外音:這就是所謂的“將請(qǐng)求盡量攔截在系統(tǒng)上游”,瀏覽器/APP層就能攔截80%+的請(qǐng)求。
不過(guò),端上的攔截只能擋住普通用戶(hù)(99%的用戶(hù)是普通用戶(hù)),程序員firebug一抓包,寫(xiě)個(gè)for循環(huán)直接調(diào)用后端http接口,js攔截根本不起作用,這下怎么辦?
(2) 站點(diǎn)層的請(qǐng)求攔截
如何抗住程序員寫(xiě)for循環(huán)調(diào)用http接口,首先要確定用戶(hù)的唯一標(biāo)識(shí),對(duì)于頻繁訪問(wèn)的用戶(hù)予以攔截。
用什么來(lái)做用戶(hù)的唯一標(biāo)識(shí)??
ip?cookie-id?別想得太復(fù)雜,購(gòu)票類(lèi)業(yè)務(wù)都需要登錄,用uid就能標(biāo)識(shí)用戶(hù)。
在站點(diǎn)層,對(duì)同一個(gè)uid的請(qǐng)求進(jìn)行計(jì)數(shù)和限速,例如:一個(gè)uid,5秒只準(zhǔn)透過(guò)1個(gè)請(qǐng)求,這樣又能攔住99%的for循環(huán)請(qǐng)求。
一個(gè)uid,5s只透過(guò)一個(gè)請(qǐng)求,其余的請(qǐng)求怎么辦?
緩存,頁(yè)面緩存,5秒內(nèi)到達(dá)站點(diǎn)層的其他請(qǐng)求,均返回上次返回的頁(yè)面。
畫(huà)外音:車(chē)次查詢(xún)和余票查詢(xún)都能夠這么做,既能保證用戶(hù)體驗(yàn)(至少?zèng)]有返回404頁(yè)面),又能保證系統(tǒng)的健壯性(利用頁(yè)面緩存,把請(qǐng)求攔截在站點(diǎn)層了)。
OK,通過(guò)計(jì)數(shù)、限速、頁(yè)面緩存攔住了99%的普通程序員,但仍有些高端程序員,例如黑客,控制了10w個(gè)肉雞,手里有10w個(gè)uid,同時(shí)發(fā)請(qǐng)求,這下怎么辦?
(3) 服務(wù)層的請(qǐng)求攔截
并發(fā)的請(qǐng)求已經(jīng)到了服務(wù)層,如何進(jìn)攔截?
服務(wù)層非常清楚業(yè)務(wù)的庫(kù)存,非常清楚數(shù)據(jù)庫(kù)的抗壓能力,可以根據(jù)這兩者進(jìn)行削峰限速。
例如,業(yè)務(wù)服務(wù)很清楚的知道,一列火車(chē)只有2000張車(chē)票,此時(shí)透?jìng)?0w個(gè)請(qǐng)求去數(shù)據(jù)庫(kù),是沒(méi)有意義的。
畫(huà)外音:假如數(shù)據(jù)庫(kù)每秒只能抗500個(gè)寫(xiě)請(qǐng)求,就只透?jìng)?00個(gè)。
用什么削峰?
請(qǐng)求隊(duì)列。
對(duì)于寫(xiě)請(qǐng)求,做請(qǐng)求隊(duì)列,每次只透?jìng)饔邢薜膶?xiě)請(qǐng)求去數(shù)據(jù)層(下訂單,支付這樣的寫(xiě)業(yè)務(wù))。
只有2000張火車(chē)票,即使10w個(gè)請(qǐng)求過(guò)來(lái),也只透?jìng)?000個(gè)去訪問(wèn)數(shù)據(jù)庫(kù):
- 如果前一批請(qǐng)求均成功,再放下一批
- 如果前一批請(qǐng)求庫(kù)存已經(jīng)不足,則后續(xù)請(qǐng)求全部返回“已售罄”
對(duì)于讀請(qǐng)求,怎么優(yōu)化?
cache抗,不管是memcached還是redis,單機(jī)抗個(gè)每秒10w應(yīng)該都是沒(méi)什么問(wèn)題的。
畫(huà)外音:緩存做水平擴(kuò)展,很容易線性擴(kuò)容。
如此削峰限流,只有非常少的寫(xiě)請(qǐng)求,和非常少的讀緩存mis的請(qǐng)求會(huì)透到數(shù)據(jù)層去,又有99%的請(qǐng)求被攔住了。
(4) 數(shù)據(jù)庫(kù)層?
經(jīng)過(guò)前三層的優(yōu)化:
- 瀏覽器攔截了80%請(qǐng)求
- 站點(diǎn)層攔截了99%請(qǐng)求,并做了頁(yè)面緩存
- 服務(wù)層根據(jù)業(yè)務(wù)庫(kù)存,以及數(shù)據(jù)庫(kù)抗壓能力,做了寫(xiě)請(qǐng)求隊(duì)列與數(shù)據(jù)緩存
你會(huì)發(fā)現(xiàn),每次透到數(shù)據(jù)庫(kù)層的請(qǐng)求都是可控的。
db基本就沒(méi)什么壓力了,閑庭信步。
畫(huà)外音:這類(lèi)業(yè)務(wù)數(shù)據(jù)量不大,無(wú)需分庫(kù),數(shù)據(jù)庫(kù)做一個(gè)高可用就行。
此時(shí),透2000個(gè)到數(shù)據(jù)庫(kù),全部成功,請(qǐng)求有效率100%。
畫(huà)外音:優(yōu)化前,10w個(gè)請(qǐng)求0個(gè)成功,有效性0%。
按照上面的優(yōu)化方案,其實(shí)壓力最大的反而是站點(diǎn)層,假設(shè)真實(shí)有效的請(qǐng)求數(shù)是每秒100w,這部分的壓力怎么處理?
解決方向有兩個(gè):?
- 站點(diǎn)層水平擴(kuò)展,通過(guò)加機(jī)器擴(kuò)容,一臺(tái)抗5000,200臺(tái)搞定;
- 服務(wù)降級(jí),拋棄請(qǐng)求,例如拋棄50%;
原則是要保護(hù)系統(tǒng),不能讓所有用戶(hù)都失敗。
站點(diǎn)層限速,是每個(gè)uid的請(qǐng)求計(jì)數(shù)放到redis里么?吞吐量很大情況下,高并發(fā)訪問(wèn)redis,網(wǎng)絡(luò)帶寬會(huì)不會(huì)成為瓶頸?
同一個(gè)uid計(jì)數(shù)與限速,如果擔(dān)心訪問(wèn)redis帶寬成為瓶頸,可以這么優(yōu)化:
- 計(jì)數(shù)直接放在內(nèi)存,這樣就省去了網(wǎng)絡(luò)請(qǐng)求;
- 在nginx層做7層均衡,讓一個(gè)uid的請(qǐng)求落到同一個(gè)機(jī)器上;
畫(huà)外音:這個(gè)計(jì)數(shù)對(duì)數(shù)據(jù)一致性、準(zhǔn)確性要求不高,即使服務(wù)重啟計(jì)數(shù)丟了,大不了重新開(kāi)始計(jì)。
除了系統(tǒng)上的優(yōu)化,產(chǎn)品與業(yè)務(wù)還能夠做一些折衷,降低架構(gòu)難度。
- 業(yè)務(wù)折衷一:一般來(lái)說(shuō),下單和支付放在同一個(gè)流程里,能夠提高轉(zhuǎn)化率。對(duì)于秒殺場(chǎng)景,產(chǎn)品上,下單流程和支付流程異步,放在兩個(gè)環(huán)節(jié)里,能夠降低數(shù)據(jù)庫(kù)寫(xiě)壓力。以12306為例,下單成功后,系統(tǒng)占住庫(kù)存,45分鐘之內(nèi)支付即可。
- 業(yè)務(wù)折衷二?:一般來(lái)說(shuō),所有用戶(hù)規(guī)則相同,體驗(yàn)會(huì)更好。對(duì)于秒殺場(chǎng)景,產(chǎn)品上,不同地域分時(shí)售票,雖然不是所有用戶(hù)規(guī)則相同,但能夠極大降低系統(tǒng)壓力。北京9:00開(kāi)始售票,上海9:30開(kāi)始售票,廣州XX開(kāi)始售票,能夠分擔(dān)系統(tǒng)壓力。
- 業(yè)務(wù)折衷三?:秒殺場(chǎng)景,由于短時(shí)間內(nèi)并發(fā)較大,系統(tǒng)返回較慢,用戶(hù)心情十分焦急,可能會(huì)頻繁點(diǎn)擊按鈕,對(duì)系統(tǒng)造成壓力。產(chǎn)品上可以?xún)?yōu)化為,一旦點(diǎn)擊,不管系統(tǒng)是否返回,按鈕立刻置灰,不給用戶(hù)機(jī)會(huì)頻繁點(diǎn)擊。
- 業(yè)務(wù)折衷四?:一般來(lái)說(shuō),顯示具體的庫(kù)存數(shù)量,能夠加強(qiáng)用戶(hù)體驗(yàn)。對(duì)于秒殺場(chǎng)景,產(chǎn)品上,只顯示有/無(wú)車(chē)票,而不是顯示具體票數(shù)目,能夠降低緩存淘汰率。
畫(huà)外音:顯示庫(kù)存會(huì)淘汰N次,顯示有無(wú)只會(huì)淘汰1次。更多的,用戶(hù)關(guān)注是否有票,而不是票有幾張。
無(wú)論如何,產(chǎn)品技術(shù)運(yùn)營(yíng)一起,目標(biāo)是一致的,把事情做好,不存在誰(shuí)是甲方,誰(shuí)是乙方的關(guān)系。
總結(jié)
對(duì)于并發(fā)高,鎖沖突小的業(yè)務(wù),可以采用《??并發(fā)扣款,如何保證一致性????》中的方法保障一致性。
對(duì)于秒殺類(lèi)業(yè)務(wù),除了業(yè)務(wù)折衷,架構(gòu)設(shè)計(jì)上主要有兩大優(yōu)化方向:
- 盡量將請(qǐng)求攔截在系統(tǒng)上游;
- 讀多寫(xiě)少用緩存;?