《??并發(fā)扣款，如何保證一致性？???》一文，描述了高并發(fā)情況下，并發(fā)扣款的一致性，冪等性，以及ABA問題。

很有朋友有疑問：如果存在一個(gè)大客戶，這一個(gè)客戶并發(fā)量就非常高，版本號(hào)比對(duì)會(huì)導(dǎo)致大量的更新失敗。于是推出，這個(gè)方案不適用于高并發(fā)場(chǎng)景。

究竟是不是這樣呢？大家對(duì)高并發(fā)是不是有什么誤解呢？

?我經(jīng)常說，任何脫離業(yè)務(wù)場(chǎng)景的架構(gòu)設(shè)計(jì)都是耍流氓，今天來聊一聊三個(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, …)?

這些信息的讀寫有一個(gè)特點(diǎn)，都會(huì)帶上uid/gid/msgid屬性。

例如，拉取好友列表：

select friend_id from user_friends 
where uid=$uid;

在用戶量很大，并發(fā)量很大時(shí)，不同用戶/群/消息數(shù)據(jù)的讀寫并沒有鎖沖突。

畫外音：10W個(gè)用戶同時(shí)讀寫，彼此沒有鎖沖突。?

只有當(dāng)，同一個(gè)用戶，很短的時(shí)間內(nèi)，有大量并發(fā)時(shí)，才可能存在鎖沖突。

畫外音：例如，1個(gè)用戶，1秒鐘讀寫1W次。?

這類場(chǎng)景下，使用《??并發(fā)扣款，如何保證一致性？???》中的CAS樂觀來解決同一個(gè)用戶的并發(fā)沖突一致性，是絕對(duì)沒有問題的。

二、微博?

微博的核心業(yè)務(wù)是feed流：

• ?發(fā)消息，寫操作
• ?刷消息，讀操作

微博業(yè)務(wù)顯然是讀多寫少的，在用戶刷消息時(shí)，自己feed流里的消息，是由別人發(fā)出的。

查看自己主頁(yè)feed流，最樸素的實(shí)現(xiàn)方法是：

• 拉取自己關(guān)注的用戶id_list；
• 拉取這些用戶最近N條消息；
• 將這N*id_list條消息排序；
• 返回第一頁(yè)消息，得到自己主頁(yè)feed流；

在用戶量很大，并發(fā)量很大時(shí)，會(huì)有一定數(shù)據(jù)的讀寫鎖沖突。

畫外音：不像QQ，基本是讀寫自己的數(shù)據(jù)，微博要寫自己的數(shù)據(jù)，讀別人的數(shù)據(jù)。?

這類場(chǎng)景下，《讀擴(kuò)散，寫擴(kuò)散，終于講清楚了！》中提到的讀擴(kuò)散，寫擴(kuò)散，也是常見的解決方案。

三、12306?

12306的核心業(yè)務(wù)是：

• ?查票，讀操作
• ?買票，寫操作

stock(id, num) // 某一列車有多少?gòu)堄嗥?/span>

在用戶量很大，并發(fā)量很大時(shí)，有極大的鎖沖突。

畫外音：這個(gè)業(yè)務(wù)，數(shù)據(jù)量并不大。?

這類“秒殺”業(yè)務(wù)，如果不做特殊的優(yōu)化，數(shù)據(jù)庫(kù)很容易死鎖卡死，沒有任何人能買票成功。

這類“秒殺”業(yè)務(wù)，有什么常見的優(yōu)化手段呢？

一般來說，系統(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ù)讀寫鎖沖突嚴(yán)重，并發(fā)高響應(yīng)慢，幾乎所有請(qǐng)求都超時(shí)，訪問流量大，下單成功的有效流量小。

一趟火車2000張票，200w個(gè)人同時(shí)來買，沒有人能買成功，請(qǐng)求有效率為0。

畫外音：此時(shí)系統(tǒng)的效率，還不如線下售票窗口。

(2) 充分利用緩存。

秒殺買票，這是一個(gè)典型的讀多寫少的業(yè)務(wù)場(chǎng)景：

• 車次查詢，讀，量大
• 余票查詢，讀，量大
• 下單和支付，寫，量小

一趟火車2000張票，200w個(gè)人同時(shí)來買，最多2000個(gè)人下單成功，其他人都是查詢庫(kù)存，寫比例只有0.1%，讀比例占99.9%，非常適合使用緩存來優(yōu)化。

秒殺業(yè)務(wù)，常見的系統(tǒng)分層架構(gòu)如何？

秒殺業(yè)務(wù)，可以使用典型的服務(wù)化分層架構(gòu)：

• 端（瀏覽器/APP），最上層，面向用戶
• 站點(diǎn)層，訪問后端數(shù)據(jù)，拼裝html/json返回
• 服務(wù)層，屏蔽底層數(shù)據(jù)細(xì)節(jié)，提供數(shù)據(jù)訪問
• 數(shù)據(jù)層，DB存儲(chǔ)庫(kù)存，當(dāng)然也有緩存

這四層分別應(yīng)該如何優(yōu)化呢？

(1) 端上的請(qǐng)求攔截（瀏覽器/APP）

想必春節(jié)大家都玩過微信的搖一搖搶紅包，用戶每搖一次，真的就會(huì)往后端發(fā)送一次請(qǐng)求么？

回顧搶票的場(chǎng)景，用戶點(diǎn)擊“查詢”按鈕之后，系統(tǒng)卡頓，用戶著急，會(huì)不自覺的再去頻繁點(diǎn)擊“查詢”，不但沒用，反而平白無故增加系統(tǒng)負(fù)載，平均一個(gè)用戶點(diǎn)5次，80%的請(qǐng)求是這么多出來的。

JS層面，可以限制用戶在x秒之內(nèi)只能提交一次請(qǐng)求，從而降低系統(tǒng)負(fù)載。

畫外音：頻繁提交，可以友好提示“頻率過快”。

APP層面，可以做類似的事情，雖然用戶瘋狂的在搖微信搶紅包，但其實(shí)x秒才向后端發(fā)起一次請(qǐng)求。

?畫外音：這就是所謂的“將請(qǐng)求盡量攔截在系統(tǒng)上游”，瀏覽器/APP層就能攔截80%+的請(qǐng)求。

不過，端上的攔截只能擋住普通用戶（99%的用戶是普通用戶），程序員firebug一抓包，寫個(gè)for循環(huán)直接調(diào)用后端http接口，js攔截根本不起作用，這下怎么辦？

(2) 站點(diǎn)層的請(qǐng)求攔截

如何抗住程序員寫for循環(huán)調(diào)用http接口，首先要確定用戶的唯一標(biāo)識(shí)，對(duì)于頻繁訪問的用戶予以攔截。

用什么來做用戶的唯一標(biāo)識(shí)？?

ip？cookie-id？別想得太復(fù)雜，購(gòu)票類業(yè)務(wù)都需要登錄，用uid就能標(biāo)識(shí)用戶。

在站點(diǎn)層，對(duì)同一個(gè)uid的請(qǐng)求進(jìn)行計(jì)數(shù)和限速，例如：一個(gè)uid，5秒只準(zhǔn)透過1個(gè)請(qǐng)求，這樣又能攔住99%的for循環(huán)請(qǐng)求。

一個(gè)uid，5s只透過一個(gè)請(qǐng)求，其余的請(qǐng)求怎么辦？

緩存，頁(yè)面緩存，5秒內(nèi)到達(dá)站點(diǎn)層的其他請(qǐng)求，均返回上次返回的頁(yè)面。

畫外音：車次查詢和余票查詢都能夠這么做，既能保證用戶體驗(yàn)（至少?zèng)]有返回404頁(yè)面），又能保證系統(tǒng)的健壯性（利用頁(yè)面緩存，把請(qǐng)求攔截在站點(diǎn)層了）。

OK，通過計(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ù)很清楚的知道，一列火車只有2000張車票，此時(shí)透?jìng)?0w個(gè)請(qǐng)求去數(shù)據(jù)庫(kù)，是沒有意義的。

畫外音：假如數(shù)據(jù)庫(kù)每秒只能抗500個(gè)寫請(qǐng)求，就只透?jìng)?00個(gè)。

用什么削峰？

請(qǐng)求隊(duì)列。

對(duì)于寫請(qǐng)求，做請(qǐng)求隊(duì)列，每次只透?jìng)饔邢薜膶懻?qǐng)求去數(shù)據(jù)層（下訂單，支付這樣的寫業(yè)務(wù)）。

只有2000張火車票，即使10w個(gè)請(qǐng)求過來，也只透?jìng)?000個(gè)去訪問數(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)該都是沒什么問題的。

畫外音：緩存做水平擴(kuò)展，很容易線性擴(kuò)容。

如此削峰限流，只有非常少的寫請(qǐng)求，和非常少的讀緩存mis的請(qǐng)求會(huì)透到數(shù)據(jù)層去，又有99%的請(qǐng)求被攔住了。

(4) 數(shù)據(jù)庫(kù)層?

經(jīng)過前三層的優(yōu)化：

• 瀏覽器攔截了80%請(qǐng)求
• 站點(diǎn)層攔截了99%請(qǐng)求，并做了頁(yè)面緩存
• 服務(wù)層根據(jù)業(yè)務(wù)庫(kù)存，以及數(shù)據(jù)庫(kù)抗壓能力，做了寫請(qǐng)求隊(duì)列與數(shù)據(jù)緩存

你會(huì)發(fā)現(xiàn)，每次透到數(shù)據(jù)庫(kù)層的請(qǐng)求都是可控的。

db基本就沒什么壓力了，閑庭信步。

畫外音：這類業(yè)務(wù)數(shù)據(jù)量不大，無需分庫(kù)，數(shù)據(jù)庫(kù)做一個(gè)高可用就行。

此時(shí)，透2000個(gè)到數(shù)據(jù)庫(kù)，全部成功，請(qǐng)求有效率100%。

畫外音：優(yōu)化前，10w個(gè)請(qǐng)求0個(gè)成功，有效性0%。

按照上面的優(yōu)化方案，其實(shí)壓力最大的反而是站點(diǎn)層，假設(shè)真實(shí)有效的請(qǐng)求數(shù)是每秒100w，這部分的壓力怎么處理？

解決方向有兩個(gè)：?

• 站點(diǎn)層水平擴(kuò)展，通過加機(jī)器擴(kuò)容，一臺(tái)抗5000，200臺(tái)搞定；
• 服務(wù)降級(jí)，拋棄請(qǐng)求，例如拋棄50%；

原則是要保護(hù)系統(tǒng)，不能讓所有用戶都失敗。

站點(diǎn)層限速，是每個(gè)uid的請(qǐng)求計(jì)數(shù)放到redis里么？吞吐量很大情況下，高并發(fā)訪問redis，網(wǎng)絡(luò)帶寬會(huì)不會(huì)成為瓶頸？

同一個(gè)uid計(jì)數(shù)與限速，如果擔(dān)心訪問redis帶寬成為瓶頸，可以這么優(yōu)化：

• 計(jì)數(shù)直接放在內(nèi)存，這樣就省去了網(wǎng)絡(luò)請(qǐng)求；
• 在nginx層做7層均衡，讓一個(gè)uid的請(qǐng)求落到同一個(gè)機(jī)器上；

畫外音：這個(gè)計(jì)數(shù)對(duì)數(shù)據(jù)一致性、準(zhǔn)確性要求不高，即使服務(wù)重啟計(jì)數(shù)丟了，大不了重新開始計(jì)。

除了系統(tǒng)上的優(yōu)化，產(chǎn)品與業(yè)務(wù)還能夠做一些折衷，降低架構(gòu)難度。

• 業(yè)務(wù)折衷一：一般來說，下單和支付放在同一個(gè)流程里，能夠提高轉(zhuǎn)化率。對(duì)于秒殺場(chǎng)景，產(chǎn)品上，下單流程和支付流程異步，放在兩個(gè)環(huán)節(jié)里，能夠降低數(shù)據(jù)庫(kù)寫壓力。以12306為例，下單成功后，系統(tǒng)占住庫(kù)存，45分鐘之內(nèi)支付即可。
• 業(yè)務(wù)折衷二?：一般來說，所有用戶規(guī)則相同，體驗(yàn)會(huì)更好。對(duì)于秒殺場(chǎng)景，產(chǎn)品上，不同地域分時(shí)售票，雖然不是所有用戶規(guī)則相同，但能夠極大降低系統(tǒng)壓力。北京9:00開始售票，上海9:30開始售票，廣州XX開始售票，能夠分擔(dān)系統(tǒng)壓力。
• 業(yè)務(wù)折衷三?：秒殺場(chǎng)景，由于短時(shí)間內(nèi)并發(fā)較大，系統(tǒng)返回較慢，用戶心情十分焦急，可能會(huì)頻繁點(diǎn)擊按鈕，對(duì)系統(tǒng)造成壓力。產(chǎn)品上可以優(yōu)化為，一旦點(diǎn)擊，不管系統(tǒng)是否返回，按鈕立刻置灰，不給用戶機(jī)會(huì)頻繁點(diǎn)擊。
• 業(yè)務(wù)折衷四?：一般來說，顯示具體的庫(kù)存數(shù)量，能夠加強(qiáng)用戶體驗(yàn)。對(duì)于秒殺場(chǎng)景，產(chǎn)品上，只顯示有/無車票，而不是顯示具體票數(shù)目，能夠降低緩存淘汰率。

畫外音：顯示庫(kù)存會(huì)淘汰N次，顯示有無只會(huì)淘汰1次。更多的，用戶關(guān)注是否有票，而不是票有幾張。

無論如何，產(chǎn)品技術(shù)運(yùn)營(yíng)一起，目標(biāo)是一致的，把事情做好，不存在誰是甲方，誰是乙方的關(guān)系。

總結(jié)

對(duì)于并發(fā)高，鎖沖突小的業(yè)務(wù)，可以采用《??并發(fā)扣款，如何保證一致性？???》中的方法保障一致性。

對(duì)于秒殺類業(yè)務(wù)，除了業(yè)務(wù)折衷，架構(gòu)設(shè)計(jì)上主要有兩大優(yōu)化方向：

• 盡量將請(qǐng)求攔截在系統(tǒng)上游；
• 讀多寫少用緩存；?