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