從這一節開始，開始介紹當拿到一個System Design問題時候應該如何處理。

-----------------------------分隔符------------------------------------------------------------------------------------

系統設計過程：

• Step 1  約束和用例
• Step 2  抽象設計
• Step 3  理解瓶頸
• Step 4  可擴充套件性設計

Step 1  約束和用例

和演算法設計相同，系統設計問題同樣也沒有得到全面而明確的定義。考慮一下上一篇文章中提到的URL縮短服務（設計一個類似“bit.ly”的URL縮短服務），對於這個問題其實有許多不明確的地方。再沒有了解清楚的情況下，設計出一個恰當的解決方案是幾乎不可能的事情。

在拿到一個問題的時候，第一件事情是要明確系統的約束和系統需要滿足哪些用例。通常，在面試中，每部分面試官想考察的是你能否立刻獲取這個問題的需求，同時設計一個能夠覆蓋滿足這些需求的解決方案。永遠不要期待能夠在一個問題沒有清楚地被表述的時候能夠解決它！

舉個例子來說，URL縮短服務可能受眾只有幾千的使用者，但每個使用者可能會共享數百萬個URL。它可能需要處理短URL上數以百萬的點選，也有可能點選量只有幾十。這個服務可能需要對每個短URL提供擴充套件性的統計（這會增加資料儲存量），當然也有可能沒必要提供這個功能。

下面以URL縮短服務為例子，分析約束和用例：

用例（系統需要完成的功能）：

• 縮短URL：將一個長URL轉換為一個短URL
• 重定向：接收到一個短URL後，重定向到長URL，即定向到真實地址
• 自定義URL功能
• 統計分析功能
• 連結自動過期（為短URL設定expiration time）
• 手動刪除連結
• UI或者API（這個service是一個有介面UI可供直接操作的web service或者website還是提供API供其他服務呼叫）

在實際場景下，可能並不是上面都需要實現。在我們後文的討論中，暫時不考慮後面斜體的功能部分。

約束（效能指標）：（do some math！）

• 每月新增URL：100million
• 每月request數：1billion（每個URL的生命週期為1-2周，在此假設為平均值~10天。假設點選數為1次/天，所以100million × 10days × 1 click/day = 1billion/month）
  下圖是估算這個值的方法，可以參考一下：
• 
  
• 10%的流量流向縮短URL服務，90%流量流向重定向
• 每秒request數：400+（40：縮短；360：重定向）
• 5年內6billion urls
• 每個URL大小為500位元組
• 每個URL的hash值為6位元組
• 五年時間，url總大小為3TB，hash總大小為36GB
• 每秒寫入的新資料約為20KB

上面的資料實際上都是估算的，為了能夠得到儘可能準確的估算，實際上是需要更多的以往資料和經驗來做支援的！所以，必要的資料準備是肯定的。

Step 2、Step 3、Step 4    未完待續...