系統設計面試題 實現Twitter時間線和搜尋

設計facebook feed和設計facebook搜尋都是類似的問題。

收集需求並確定問題的範圍。提出問題以澄清用例和約束。討論假設。

總則時間線

搜尋每月150 tb新內容

每秒10萬個讀取請求

每秒6000條推文

每秒擴散6萬條推文

每秒4000個搜尋請求

方便的轉換指南：

概述所有重要元件的高階設計。

深入了解每個核心元件的細節。

我們可以在關聯式資料庫中儲存使用者自己的tweet來填充使用者時間線（來自使用者的活動）。我們應該討論選擇sql還是nosql的用例和權衡。

發布tweet和建立home時間線（使用者關注的人的活動）更為棘手。將tweet擴散給所有關注者（每秒擴散6萬條）將使傳統的關聯式資料庫過載。我們可能希望選擇乙個具有快速寫入的資料儲存，例如nosql資料庫或記憶體快取。從記憶體中順序讀取1 mb大約需要250微秒，而從ssd讀取需要4倍的時間，從磁碟讀取需要80倍的時間。

如果我們的快取是redis，我們可以使用具有以下結構的redis列表：

tweet n+2                   tweet n+1                   tweet n

| 8 bytes 8 bytes 1 byte | 8 bytes 8 bytes 1 byte | 8 bytes 8 bytes 1 byte |
| tweet_id user_id meta | tweet_id user_id meta | tweet_id user_id meta |

新的tweet將被放置在快取中，快取填充使用者的關注時間線（使用者跟蹤的人的活動）。

我們將使用rest api：

$ curl -x post --data '' \

response:

對於內部通訊，我們可以使用遠端過程呼叫。

rest api: 

$ curl

response:

,

,,

restapi與關注 timeline類似，只是所有tweet都來自使用者，而不是使用者關注的人。

在搜尋集群（即lucene）中查詢結果：

rest api:

$ curl

除了與給定查詢匹配的tweet外，響應與 timeline類似。

確定並解決瓶頸，給出限制條件。 

說明您將1）基準測試/負載測試，2）瓶頸概況，3）在評估備選方案和權衡時解決瓶頸，4）重複。

討論在初始設計中可能遇到的瓶頸以及如何解決每個瓶頸是很重要的。例如，通過新增帶有多個web伺服器的負載均衡可以解決哪些問題？cdn？主從複製？每種方法有哪些選擇和權衡？

擴散服務是乙個潛在的瓶頸。擁有數百萬粉絲的twitter使用者可能需要幾分鐘的時間來完成他們的tweet擴散過程。（譯者：後面還有一句話，我沒理解意思）：this could lead to race conditions with @replies to the tweet, which we could mitigate by re-ordering the tweets at serve time.

我們還可以避免從關注度很高的使用者那裡散播tweet。在拉取使用者時間線時，通過搜尋那些大v的推文list，將它們merge到使用者的時間線中，再返回list (譯者：其實就是寫擴散的時候，大v不擴散，然後讀寫擴散結合去做feed流)

其他優化包括：

在tweet info服務中只儲存乙個月的tweet

僅在使用者資訊服務中儲存活躍使用者

搜尋集群可能需要將tweet儲存在記憶體中以保持低延遲

我們還希望通過sql資料庫解決瓶頸問題。

儘管記憶體快取可以減少資料庫的負載，但僅sql讀取副本不太可能足以處理cache miss。我們可能需要採用額外的sql擴充套件模式。

大量的寫操作將使單個sql寫操作主從裝置無法承受，這也表明需要額外的擴充套件技術。

我們還應該考慮將一些資料移動到nosql資料庫。

根據問題範圍和剩餘時間，需要深入研究的其他主題。

nosql

面試題 秒殺系統設計

秒殺業務的特點就是多個人讀乙個資料，難點就是讀寫衝突，鎖情況特別的嚴重。所以我們盡量不要讓請求落在資料庫上去，讓請求攔截在系統的上游。解決思路 1 限流 遮蔽掉無用的流量，允許少部分流量流向後端。2 削峰 瞬時大流量峰值容易壓垮系統。常用的消峰方法有非同步處理 快取和訊息中介軟體等技術 前端優化 1...

面試題 設計instagram

約束high level db design 詳細設計 擴充套件資訊流設計 使用者可以上傳 分享 關注其他人，亦可以看到自己的和好友的top 功能性 根據名稱搜尋 使用者關注他人 生成和展示資訊流，包含所有關注的人的top 非功能性 5.高可用 6.低時延 資訊流產生時延 200ms 7.ap系統 ...

設計模式面試題

參考 常用的設計模式彙總，超詳細！這個模式本身很簡單而且使用在業務較簡單的情況下。一般用於小專案或者具體產品很少擴充套件的情況 這樣工廠類才不用經常更改 它由三種角色組成 來用類圖來清晰的表示下的它們之間的關係 抽象工廠模式 先來認識下什麼是產品族 位於不同產品等級結構中，功能相關聯的產品組成的家族...