系統設計面試：設計Twitter

「設計Twitter」是動態產生問題的經典代表。它看起來很簡單——發一則推文、讀一條時間軸——但真正有趣的部分，是如何在規模化場景下產生每個使用者的主時間軸，而正確答案是一種混合扇出策略。面試官想看到你發現兩種單純方案都會失效，並一步步推理出這種混合方案。

按部就班地推進：先釐清需求，再估算讀寫比例，設計推文儲存，然後設計時間軸——比較寫時扇出與讀時扇出，並得出能處理名人問題的混合方案。以下的解析遵循這條路徑。

1. 釐清需求

把範圍限定在核心的動態問題上。使用者發推文，關注他人，並閱讀一條把所有關注對象的推文按最新優先合併起來的主時間軸。

功能性：發推文、關注／取消關注、主時間軸（你關注的人）、使用者時間軸（某一位作者）；基礎搜尋除非被要求，否則不在範圍內。
非功能性：讀取非常密集、時間軸讀取低延遲、高可用性；時間軸的最終一致性是可以接受的。
需要澄清：媒體內容、回覆／話題串以及排序——認可它們的存在，然後將本輪範圍限定為按時間順序排列的動態。

2. 估算規模與讀寫比例

這個比例驅動了整個設計。讀取遠遠超過寫入——使用者刷時間軸的頻率遠高於發帖的頻率。在擁有數億使用者的情況下，系統必須讓時間軸讀取變得廉價，即使這會讓寫入變得更昂貴。這一個觀察就指向了預先計算時間軸這一方向。

3. 推文儲存

推文本身是簡單的、以附加寫入為主的資料。把它們儲存在按推文ID分區的水平分片儲存中（使用類似Snowflake ID這樣可按時間排序的ID，使順序天然內嵌其中）。一個單獨的社交圖儲存保存關注者／被關注者關係。

推文：分散式儲存，按推文ID分片；可按時間排序的ID能以低成本提供按時間順序的排序。
社交圖：誰關注誰，針對「取得X的所有關注者」和「取得X關注的所有人」這兩類查詢做了最佳化。
快取（Redis）保存熱資料——最近的推文和預先計算好的時間軸。

4. 時間軸產生：寫時扇出對讀時扇出

這是問題的核心。寫時扇出（推送）會在發帖時把每則新推文插入每個關注者預先計算好的時間軸清單中——時間軸讀取變成一次廉價的快取查詢，但擁有數百萬關注者的人發一則貼文就會觸發數百萬次寫入。讀時扇出（拉取）會在讀取時，把你關注的所有人最近的推文合併起來建構時間軸——寫入廉價，但對於關注大量帳號的使用者來說，讀取會變得緩慢且昂貴。

寫時扇出：讀取快，寫入昂貴；非常適合一般使用者。
讀時扇出：寫入便宜，讀取昂貴；對擁有海量關注者的帳號是必要的。

5. 名人問題與混合方案

兩種純粹的方案都無法單獨取勝，因此要把它們結合起來。對絕大多數使用者使用寫時扇出，但對擁有極大量關注者的「名人」帳號，在寫入時不要對其推文做扇出。相反，在讀取時，把某個關注者預先計算好的時間軸與他所關注的少數幾位名人的即時拉取結果合併起來。這樣既能限制寫入放大，又能保持讀取速度——這正是面試官想聽到的答案。

6. 需要說出來的取捨

最後點出這些張力：寫入放大與讀取延遲（整個扇出決策）、預先計算時間軸的儲存成本與重新計算它們之間的取捨，以及一致性——推文出現在關注者時間軸中有幾秒延遲是可以接受的，因此最終一致性讓你能夠擴展規模。明確說出混合方案的門檻（你如何界定「名人」）體現了資深的判斷力。

藉助即時輔助練習Twitter的系統設計

Natively的系統設計面試助手能在實際面試中幫你保持結構清晰——即時建議接下來該涵蓋的面向，並呈現取捨，一切都在你自己的裝置上完成。