最近有不少晉升、跳槽的同學在背景留言，說他們在考核或面試上，都不約而同地遇到了「高并發架構設計」難題。
确實，從普通程式員到架構師，從程式設計思維更新到架構思維，“高并發架構設計”是繞不開的，如今更成為了進大廠的高頻面試題。
困難點是，很多人在工作中沒有高并發項目場景，今天通過模拟設計一個支援 10 億 級使用者體量的微網誌系統，帶你身臨其境地實踐高并發架構設計。
這個設計案例，來自同程旅行交通首席架構師李智慧的新專欄《高并發架構實戰課》，主要選取15+ 個典型高并發系統案例，采用架構師最常用的“軟體設計文檔”形式，為你呈現架構師的高并發架構設計思路，想看完整專欄可直接拉到底部。
我們知道微網誌的一個特點是：當明星大 V 釋出一條比較有話題性的動态，比如鹿晗宣布，就會引起大量的閱讀、評論和傳播。這種突發的熱點事件導緻的高并發通路會給系統帶來極大的負載壓力，處理不當甚至會導緻系統崩潰。
那麼，類似微網誌的資訊流系統架構要如何設計，才能解決熱點消息産生的突發高并發通路壓力，保障系統的可用性？
今天我們就來設計一個可以支援 10 億 級使用者體量的微網誌系統，系統名稱為“Weitter”。主要分為三步：需求分析、概要設計和詳細設計。
需求分析
Weitter 的核心功能隻有三個：發微網誌，關注好友，刷微網誌。此外，使用者還可以收藏、轉發、評論微網誌。
負載名額估算
文本内容存儲空間：100 GB/ 天
多媒體檔案存儲空間：60 TB/ 天
通路并發量估算
QPS：46296/ 秒，高峰期 QPS 按平均值 2 倍計算：10 萬 QPS
網絡帶寬：4.8 Tb/s
概要設計
從需求分析中可以看到，Weitter 的業務邏輯比較簡單，但是并發量和資料量都比較大，是以，系統架構的核心就是解決高并發的問題，系統整體部署模型如下:
圖中包括 “Get 請求”和“Post 請求”兩條鍊路。
Get 請求
使用者通路微網誌的資料中心、圖檔以及視訊等極耗帶寬的請求，絕大部分可以被 CDN 緩存命中，也就是說，4.8Tb/s 的帶寬壓力，90% 以上可以通過 CDN 消化掉。
Post 請求
用戶端不需要通過 CDN 和反向代理，而是直接通過負載均衡伺服器到達應用伺服器。應用伺服器一方面會将發表的微網誌寫入 Redis 緩存叢集，一方面寫入分片資料庫中。
詳細設計
微網誌的發表 / 訂閱問題
這是微網誌的核心業務問題，即微網誌使用者關注好友後，如何快速得到好友最新發表的微網誌内容。
當使用者線上時，我們可以使用“推模式”：建一張使用者訂閱表，使用者關注的好友發表微網誌後，立即在使用者訂閱中為該使用者插入一條記錄，記錄使用者 ID 和好友發表的微網誌 ID。
如果使用者目前不線上，那麼系統就會将該訂閱表删除，當使用者登入重新整理的時候，用“拉模式”為其重新建構清單：使用者重新整理微網誌的時候，根據其關注的好友清單，查詢每個好友近期發表的微網誌，然後将所有微網誌按照時間順序排序後建構一個清單。
緩存使用政策
微網誌整體的緩存架構采用了時間淘汰算法：緩存使用者 7 天内發表的全部微網誌。緩存的 key 為使用者 ID，value 為使用者最近 7 天發表的微網誌 ID 清單。而微網誌 ID 和微網誌内容分别作為 key 和 value 也緩存起來。
此外，對于特别熱門的微網誌内容，啟用本地緩存模式：若使用者粉絲在 100 萬 以上，緩存其 48 小時内發表的全部微網誌。應用伺服器在記憶體中緩存特别熱門的微網誌内容，應用建構微網誌重新整理頁的時候，會優先檢查微網誌 ID 對應的微網誌内容是否在本地緩存中。
資料庫分片政策
微網誌的資料庫我們采用分片部署的分布式資料庫。分片的規則采用的是使用者 ID（的 hash 值）分片：一個使用者發表的全部微網誌都會儲存到一台資料庫伺服器上。當系統需要按使用者查找其發表的微網誌的時候，隻需要通路一台伺服器就可以完成。
但是這樣做也有缺點，對于一個大 V 使用者，其資料通路會成熱點，進而導緻這台伺服器負載壓力太大。同樣，如果某個使用者頻繁發表微網誌，也會導緻這台伺服器資料增長過快。
對于用這個問題，可以通過優化緩存來改善；而某個使用者頻繁發表微網誌的問題，可以通過設定每天發表微網誌數上限來解決。
沒有真實場景如何實踐高并發架構？
案例講解基本到這，它出自極客時間的新專欄《李智慧 · 高并發架構實戰課》，專欄最吸引我的地方，就是李智慧針對“普通程式員工作中沒有真實場景，缺乏高并發架構設計實踐”的難點，制定了一套切實可行的學習方法：
帶入架構師視角，體會真實的系統設計場景；
跟着李智慧拆解 15+ 典型高并發架構案例，集衆家技術之所長；
嘗試自己進行軟體模組化，寫架構設計文檔；
這些案例大多是目前大家比較關注的高并發、高性能、高可用系統。比如網盤、搜尋引擎、短視訊應用、打車軟體、交友軟體、微網誌等。它們是高并發架構設計的優秀“課代表”，它們的技術可以解決現有的80% 以上的高并發共性問題。
最重要的是，李智慧針對這些知名的大廠應用重新進行設計，而不是分析現有這些應用是如何設計的。
李智慧是誰？
他現在是同程旅遊交通首席架構師，曾在阿裡巴巴和英特爾擔任架構師。他參與過 alibaba.com 和 Apache Spark 的架構設計與開發，也曾作為CTO上司團隊經曆了日訂單從零到一百萬的高并發技術挑戰。
他在極客時間已經開過兩門專欄課程了，分别是《從 0 開始學大資料》和《後端技術面試 38 講》，已經近 3W 人看過了，好評如潮。李智慧可以說是高并發領域真正的大牛，他把 15 年來的架構設計經驗，在專欄中傾囊相授。
上新優惠入手不虧
限時秒殺 + 密碼「BINGFA999」隻需 69
想深入學習高并發設計的朋友，拓寬自己的技能樹，推薦你深入學習。
最後我想說：一個工程師，如果不能從架構師的角度思考問題，帶領團隊，整體完成一個系統的架構設計與開發，就永遠也不會了解如何做一個架構師。
現在就是最好的學習機會，有多幹貨，看看目錄吧：
