計算性能預估

根據看微博的假設，絕大部分看微博的對象是大 V 或明星，平均每條微博觀看人數有 100 次。

延伸這個假設，假設觀看人數內只有 10% 的人會去評論這條微博，則評論微博的次數為:

2.5 億 * 100 * 10% = 25 億

而評論微博的時間段，基本上會跟看微博的時間段重合，因此評論微博的平均 TPS 計算如下:

25 億 * 60% / (4*3600) = 100K/s

非熱點事件的高性能計算架構

業務特性分析

微博評論是一個典型的寫操作，因此不能用緩存，要用負載均衡。

架構分析

因用戶量過億，直接選用 5 級負載均衡架構，包含 DNS、F5、Nginx、網關。

架構設計

附載均衡算法選擇

評論微博時需依賴登入狀態，登入狀態一般都會放在分佈式緩存上，所以評論微博將請求發給哪台業務服務器都無所謂，因此選擇輪詢或隨機算法即可。

業務服務器數量估算

評論微博兩個關鍵的處理: 內容審核和寫入存儲系統。

假設單個服務器 (32 核) 的平均處理性能約為 500/s ，那麼處理 100K/s 的 TPS 需要約 200 台服務器，再加上 20% 的預留量，大約需要 240 台服務器。

熱點事件的高可用計算架構

採用排隊機制

設計分析

因為當一篇微博發生熱點事件時，該篇微博的評論會突然增加很多，而這些評論可能很快就被洗掉了，對於發評論的人來說，即時看到自己評論的需求並沒有像發微博這麼高。

採用排隊方式，也就是先緩存請求，服務器根據自己能力慢慢做，用戶端手動刷新來看評論是否出現即可。