feed 與秒殺，撐住 10Wqps，架構方案一樣嗎？

很有朋友有疑問：如果存在一個大客戶，這一個客戶併發量就非常高，版本號比對會導致大量的更新失敗。於是推出，這個方案不適用於高併發場景。

究竟是不是這樣呢？大家對高併發是不是有什麼誤解呢？

我經常說，任何脫離業務場景的架構設計都是耍流氓，今天來聊一聊三個高併發業務場景的架構設計差異。

一、QQ

QQ 的一些核心業務有：

• 個人：user(uid, user_info, …)

• 好友：user_friends(uid, friend_id, …)

• 加入的羣：user_groups(uid, group_id, …)

• 羣：group(gid, group_info, …)

• 羣成員：group_members(gid, uid, …)

• 個人消息：msgs_user(msg_id, uid, …)

• 羣消息：msgs_group(msg_id, gid, …)

這些信息的讀寫有一個特點，都會帶上 uid/gid/msgid 屬性。

例如，拉取好友列表：

_select friend_id from user_friends _

where uid=$uid_;_

在用戶量很大，併發量很大時，不同用戶 / 羣 / 消息數據的讀寫並沒有鎖衝突。

_畫外音：_10W 個用戶同時讀寫，彼此沒有鎖衝突。

只有當，同一個用戶，很短的時間內，有大量併發時，纔可能存在鎖衝突。

_畫外音：例如，_1 個用戶，1 秒鐘讀寫 1W 次。

這類場景下，使用《併發扣款，如何保證一致性？》中的 CAS 樂觀來解決同一個用戶的併發衝突一致性，是絕對沒有問題的。

二、微博

微博的核心業務是 feed 流：

• 發消息，寫操作

• 刷消息，讀操作

微博業務顯然是讀多寫少的，在用戶刷消息時，自己 feed 流裏的消息，是由別人發出的。

查看自己主頁 feed 流，最樸素的實現方法是：

(1) 拉取自己關注的用戶 id_list；

(2) 拉取這些用戶最近 N 條消息；

(3) 將這 N*id_list 條消息排序；

(4) 返回第一頁消息，得到自己主頁 feed 流；

在用戶量很大，併發量很大時，會有一定數據的讀寫鎖衝突。

_畫外音：_不像 QQ，基本是讀寫自己的數據，微博要寫自己的數據，讀別人的數據。

這類場景下，《讀擴散，寫擴散，終於講清楚了‍！》中提到的讀擴散，寫擴散，也是常見的解決方案。

三、12306

12306 的核心業務是：

• 查票，讀操作

• 買票，寫操作

stock(id, num) // 某一列車有多少張餘票

在用戶量很大，併發量很大時，有極大的鎖衝突。

_畫外音：_這個業務，數據量並不大。

這類 “秒殺” 業務，如果不做特殊的優化，數據庫很容易死鎖卡死，沒有任何人能買票成功。

這類 “秒殺” 業務，有什麼常見的優化手段呢？

一般來說，系統上和業務上分別需要配合優化。

系統層面，秒殺業務的優化方向如何？

主要有兩項：

（1）將請求儘量攔截在系統上游，而不要讓鎖衝突落到數據庫。

傳統秒殺系統之所以掛，是因爲請求都壓到了後端數據層，數據讀寫鎖衝突嚴重，併發高響應慢，幾乎所有請求都超時，訪問流量大，下單成功的有效流量小。

一趟火車 2000 張票，200w 個人同時來買，沒有人能買成功，請求有效率爲 0。

_畫外音：_此時系統的效率，還不如線下售票窗口。

（2）充分利用緩存。

秒殺買票，這是一個典型的讀多寫少的業務場景：

• 車次查詢，讀，量大

• 餘票查詢，讀，量大

• 下單和支付，寫，量小

一趟火車 2000 張票，200w 個人同時來買，最多 2000 個人下單成功，其他人都是查詢庫存，寫比例只有 0.1%，讀比例佔 99.9%，非常適合使用緩存來優化。

秒殺業務，常見的系統分層架構如何？

秒殺業務，可以使用典型的服務化分層架構：

• 端（瀏覽器 /APP），最上層，面向用戶

• 站點層，訪問後端數據，拼裝 html/json 返回

• 服務層，屏蔽底層數據細節，提供數據訪問

• 數據層，DB 存儲庫存，當然也有緩存

這四層分別應該如何優化呢？

一、端上的請求攔截（瀏覽器 / APP）

想必春節大家都玩過微信的搖一搖搶紅包，用戶每搖一次，真的就會往後端發送一次請求麼？

回顧搶票的場景，用戶點擊 “查詢” 按鈕之後，系統卡頓，用戶着急，會不自覺的再去頻繁點擊“查詢”，不但沒用，反而平白無故增加系統負載，平均一個用戶點 5 次，80% 的請求是這麼多出來的。

JS 層面，可以限制用戶在 x 秒之內只能提交一次請求，從而降低系統負載。

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

APP 層面，可以做類似的事情，雖然用戶瘋狂的在搖微信搶紅包，但其實 x 秒才向後端發起一次請求。

_畫外音：_這就是所謂的 “將請求儘量攔截在系統上游”，瀏覽器 / APP 層就能攔截 80%+ 的請求。

不過，端上的攔截只能擋住普通用戶（99% 的用戶是普通用戶），程序員 firebug 一抓包，寫個 for 循環直接調用後端 http 接口，js 攔截根本不起作用，這下怎麼辦？

二、站點層的請求攔截

如何抗住程序員寫 for 循環調用 http 接口，首先要確定用戶的唯一標識，對於頻繁訪問的用戶予以攔截。

用什麼來做用戶的唯一標識？

ip？cookie-id？別想得太複雜，購票類業務都需要登錄，用 uid 就能標識用戶。

在站點層，對同一個 uid 的請求進行計數和限速，例如：一個 uid，5 秒只准透過 1 個請求，這樣又能攔住 99% 的 for 循環請求。

一個 uid，5s 只透過一個請求，其餘的請求怎麼辦？

緩存，頁面緩存，5 秒內到達站點層的其他請求，均返回上次返回的頁面。

畫外音：車次查詢和餘票查詢都能夠這麼做，既能保證用戶體驗（至少沒有返回 404 頁面），又能保證系統的健壯性（利用頁面緩存，把請求攔截在站點層了）。

OK，通過計數、限速、頁面緩存攔住了 99% 的普通程序員，但仍有些高端程序員，例如黑客，控制了 10w 個肉雞，手裏有 10w 個 uid，同時發請求，這下怎麼辦？

三、服務層的請求攔截

併發的請求已經到了服務層，如何進攔截？

服務層非常清楚業務的庫存，非常清楚數據庫的抗壓能力，可以根據這兩者進行削峯限速。

例如，業務服務很清楚的知道，一列火車只有 2000 張車票，此時透傳 10w 個請求去數據庫，是沒有意義的。

畫外音：假如數據庫每秒只能抗 500 個寫請求，就只透傳 500 個。

用什麼削峯？

請求隊列。

對於寫請求，做請求隊列，每次只透傳有限的寫請求去數據層（下訂單，支付這樣的寫業務）。

只有 2000 張火車票，即使 10w 個請求過來，也只透傳 2000 個去訪問數據庫：

• 如果前一批請求均成功，再放下一批

• 如果前一批請求庫存已經不足，則後續請求全部返回 “已售罄”

對於讀請求，怎麼優化？

cache 抗，不管是 memcached 還是 redis，單機抗個每秒 10w 應該都是沒什麼問題的。

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

如此削峯限流，只有非常少的寫請求，和非常少的讀緩存 mis 的請求會透到數據層去，又有 99% 的請求被攔住了。

四、數據庫層

經過前三層的優化：

• 瀏覽器攔截了 80% 請求

• 站點層攔截了 99% 請求，並做了頁面緩存

• 服務層根據業務庫存，以及數據庫抗壓能力，做了寫請求隊列與數據緩存

你會發現，每次透到數據庫層的請求都是可控的。

db 基本就沒什麼壓力了，閒庭信步。

畫外音：這類業務數據量不大，無需分庫，數據庫做一個高可用就行。

此時，透 2000 個到數據庫，全部成功，請求有效率 100%。

畫外音：優化前，10w 個請求 0 個成功，有效性 0%。

按照上面的優化方案，其實壓力最大的反而是站點層，假設真實有效的請求數是每秒 100w，這部分的壓力怎麼處理？

解決方向有兩個：

（1）站點層水平擴展，通過加機器擴容，一臺抗 5000，200 臺搞定；

（2）服務降級，拋棄請求，例如拋棄 50%；

原則是要保護系統，不能讓所有用戶都失敗。

**站點層限速，是每個 uid 的請求計數放到 redis 裏麼？**吞吐量很大情況下，高併發訪問 redis，網絡帶寬會不會成爲瓶頸？

同一個 uid 計數與限速，如果擔心訪問 redis 帶寬成爲瓶頸，可以這麼優化：

（1）計數直接放在內存，這樣就省去了網絡請求；

（2）在 nginx 層做 7 層均衡，讓一個 uid 的請求落到同一個機器上；

畫外音：這個計數對數據一致性、準確性要求不高，即使服務重啓計數丟了，大不了重新開始計。

除了系統上的優化，產品與業務還能夠做一些折衷，降低架構難度。

業務折衷一

一般來說，下單和支付放在同一個流程裏，能夠提高轉化率。對於秒殺場景，產品上，下單流程和支付流程異步，放在兩個環節裏，能夠降低數據庫寫壓力。以 12306 爲例，下單成功後，系統佔住庫存，45 分鐘之內支付即可。

業務折衷二

一般來說，所有用戶規則相同，體驗會更好。對於秒殺場景，產品上，不同地域分時售票，雖然不是所有用戶規則相同，但能夠極大降低系統壓力。北京 9:00 開始售票，上海 9:30 開始售票，廣州 XX 開始售票，能夠分擔系統壓力。

業務折衷三

秒殺場景，由於短時間內併發較大，系統返回較慢，用戶心情十分焦急，可能會頻繁點擊按鈕，對系統造成壓力。產品上可以優化爲，一旦點擊，不管系統是否返回，按鈕立刻置灰，不給用戶機會頻繁點擊。

業務折衷四

一般來說，顯示具體的庫存數量，能夠加強用戶體驗。對於秒殺場景，產品上，只顯示有 / 無車票，而不是顯示具體票數目，能夠降低緩存淘汰率。

畫外音：顯示庫存會淘汰 N 次，顯示有無只會淘汰 1 次。更多的，用戶關注是否有票，而不是票有幾張。

無論如何，產品技術運營一起，目標是一致的，把事情做好，不存在誰是甲方，誰是乙方的關係。

總結

對於併發高，鎖衝突小的業務，可以採用《併發扣款，如何保證一致性？》中的方法保障一致性。

對於 feed 類業務，可以採用《讀擴散，寫擴散，終於講清楚了！》中的架構方案，支持高併發。

對於秒殺類業務，除了業務折衷，架構設計上主要有兩大優化方向：

（1）儘量將請求攔截在系統上游；

（2）讀多寫少用緩存；

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zOuND9sLZdWrAO2ehOeY6g