系統設計面試的萬金油


萬金油: 比喻什么都能做,但什么都不擅長

系統設計是面試當中的一個常考點,是面試官考察面試者知識廣度與深度最直接的方式。

許多開發者在系統設計面試中痛苦主要是因為下面三個原因

  1. 系統設計面試屬於開放性問題,沒有一個標准的答案
  2. 缺乏開發大規模系統的經驗
  3. 對系統設計問題沒有准備

就像代碼面試一樣,那些沒有有意識地為系統設計面試做准備的求職者,大多表現不佳,尤其是在谷歌、Facebook、亞馬遜、微軟等頂級公司的面試中。在這些公司中,表現不佳的求職者得到錄用的機會非常有限。另一方面,良好的表現總是會帶來更好的待遇,因為這顯示了候選人處理復雜系統的能力。

第一步 需求分析

對我們要解決的問題確切范圍並且提出問題。設計類問題大多是開放式的,它們沒有一個正確的答案,這就是為什么在面試中盡早澄清模棱兩可的問題變得至關重要。花足夠時間定義系統最終目標的候選人總是有更好的機會在面試中取得成功,此外,由於我們只有35-40分鍾的時間來設計一個大型系統,我們應該明確我們將重點關注系統的哪些部分。

讓我們用一個設計類似twitter的服務來擴展這一點。以下是一些設計Twitter時應該首先明確的問題。

  • 用戶能夠發布推文並關注其他人嗎?
  • 我們應該設計創建和顯示用戶的時間軸嗎?
  • 推文會包含照片和視頻嗎?
  • 我們是只關注后端還是也開發前端?
  • 用戶能夠搜索推文嗎?
  • 我們需要展示熱門話題嗎?
  • 我們需要設計新的(或重要的)推文推送通知嗎?

這些問題將會決定我們的系統最終設計會是什么樣子。

第二步 系統接口定義

定義系統所需要的API,這不僅可以建立系統預期的確切規范,而且還可以確保我們沒有弄錯任何要求。 下面是我們類似Twitter服務的一些接口示例:

postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, ...)

generateTimeline(user_id, current_time, user_location, ...)

markTweetFavorite(user_id, tweet_id, timestamp, ...)

第三步 規模估計

估計我們要設計的系統的規模,有助於我們以后關注擴展、分區、負載平衡和緩存。

  • 系統的預期規模(例如,新推文的數量,推文的瀏覽數量,每秒鍾時間軸的生成數量,等等)
  • 我們需要多少存儲空間? 如果用戶可以在推特上上傳照片和視頻,我們會有不同預期的存儲空間。
  • 我們期望的網絡帶寬使用量是多少? 這對於決定我們將如何管理流量和平衡服務器之間的負載至關重要。

第四步 定義數據模型

盡早定義數據模型將闡明數據如何在系統的不同組件之間流動。之后,它將指導數據分區和管理。候選人應該能夠識別系統的各種實體,它們將如何相互作用,以及數據管理的不同方面,如存儲、傳輸、加密等。這里有一些我們的Twitter服務的實體定義。

User: UserID, Name, Email, DoB, CreationData, LastLogin, etc.
Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc.
UserFollowo: UserdID1, UserID2
FavoriteTweets: UserID, TweetID, TimeStamp

我們應該使用哪個數據庫系統? 像Cassandra這樣的NoSQL是否最適合我們的需求,或者我們應該使用類似mysql的解決方案? 我們應該使用什么樣的塊存儲來存儲照片和視頻?

第五步 高層次設計

用5-6個框圖表示我們系統的核心組件。我們應該確定從端到端解決實際問題所需的足夠多的組件。對於Twitter,在較高級別上,我們將需要多個應用程序服務器來處理所有讀/寫請求,並在它們前面使用負載均衡器進行流量分配。 如果我們假設我們將有更多的讀取流量(與寫入相比),我們可以決定使用單獨的服務器來處理這些場景。在后台,我們需要一個高效的數據庫來存儲所有的tweet並支持大量的讀取。我們還需要一個分布式文件存儲系統來存儲照片和視頻。

第六步 詳細設計

深入挖掘系統的兩三個組件,根據面試官的反饋來確定面試官更關心系統中哪部分的實現,並且進行進一步的討論。我們應該能夠提出不同的方法,它們的優缺點,並解釋為什么我們更喜歡一種方法而不是另一種方法。記住,沒有單一的答案,唯一重要的事情是考慮不同選項之間的權衡,同時牢記系統約束。

  • 由於我們將存儲大量的數據,我們應該如何划分數據以將其分布到多個數據庫?我們是否應該嘗試將一個用戶的所有數據存儲在同一個數據庫中?它會引起什么問題呢?
  • 我們將如何處理推特或關注很多人的熱門用戶?
  • 既然用戶的時間線將包含最新的(和相關的)tweets,我們是否應該嘗試以一種優化的方式存儲我們的數據,以掃描最新tweets?
  • 我們應該在哪個層引入多少緩存來加速呢?
  • 哪些組件需要更好的負載平衡?

第七步 瓶頸問題

嘗試討論盡可能多的瓶頸和不同的方法來緩解它們。

  • 我們的系統有單點故障嗎? 我們要做什么來減輕它?
  • 我們是否有足夠的數據副本,以便在失去一些服務器時仍能為用戶提供服務。
  • 類似地,我們是否有足夠多的不同服務的副本在運行,以便一些故障不會導致整個系統關閉。
  • 我們如何監控服務的表現? 當關鍵組件出現故障或性能下降時,我們是否會收到警報。

總結

總之,面試過程中的有准備和有組織是系統設計面試成功的關鍵。上述步驟將指導您在設計系統時保持跟蹤並涵蓋系統設計的不同方面。

參考: 《System Design Interview》


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM