原文鏈接：
https://www.educative.io/cour...
編者注：本文以一道經典的系統設計面試題：《如何設計TinyURL》的參考答案和解析爲例，幫助讀者更深入地瞭解在系統需求分析和設計中，需要考慮的各個方面的細節。
本文將爲大家詳細講解如何設計一個類似於TinyURL的URL縮短服務。URL縮短服務提供一個非常短小的URL以代替原來的可能較長的URL，將長的URL地址縮短。
類似的服務有：http://bit.ly，goo.gl，qlink.me,等等。
七、數據分區和複製
爲了擴展DB，我們需要對它進行分區，以便它能夠存儲數十億個URL的信息。那麼，我們需要想出一個分區方案，將數據劃分並存儲到不同的DB服務器。
a、範圍分區：我們可以根據哈希值的第一個字母將URL存儲在單獨的分區中。因此，我們在第一個分區中保存所有以字母“A”開頭的URL，在另一個分區中保存以字母“B”開頭的URL，以此類推。這種方法稱爲範圍分區。我們甚至可以將某些不太頻繁出現的字母組合到一個數據庫分區中。我們需要一個靜態分區方案，這樣就可以始終以可預測的方式來存儲/查找URL。
採用這種方法分區，主要的問題是它會導致DB服務器負載不均衡。例如，我們決定將所有以字母“E”開頭的URL放在一個DB分區中，但是後來我們發現有太多URL以字母“E”開頭。
b、哈希分區：在這個方案中，我們對存儲的對象進行哈希計算。然後根據計算出的哈希值來進行分區。在我們的示例中，我們可以使用key或者短鏈接的哈希值來確定存儲數據對象的分區。
通過哈希函數將URL隨機分佈到不同的分區中，例如，總是可以將任意的key映射到一個介於【1……256】之間的數字，這個數字代表存儲對象的分區。
這種方法仍然會導致某些分區過載，這個問題可以通過使用
en.wikipedia.org來解決。
八、緩存
我們可以緩存經常訪問的URL。通過使用一些現成的解決方案，如Memcached，可以存儲完整的URL及其對應的哈希值。應用服務器在訪問後端存儲之前，可以快速檢查緩存是否具有所需的URL。
我們應該有多少緩存？我們可以從每日流量的20%開始，並根據客戶端的使用模式調整所需的緩存服務器數量。根據《如何設計一個類似於TinyURL的網址縮短系統（一）》中的內存估計，我們需要170GB的內存來緩存20%的日常流量。由於現在的服務器可以有256GB的內存，將所有170GB的數據緩存放入一臺機器中是很容易的。或者，我們還可以使用多臺較小的服務器來存儲這些熱門URL。
哪種緩存清除策略最適合我們的需要？當緩存滿了，我們又希望替換一些更新或者更熱門的URL時，需要如何選擇呢？最近最少使用（Least Recently Used ，LRU）是一個合理的策略。在此策略下，我們首先丟棄最近最少使用的URL。我們可以使用Linked Hash Map或者其他相似的數據結構來存儲URL和哈希值，它還將跟蹤最近訪問過的URL。
爲了進一步提高效率，我們可以通過複製緩存服務器的方式在它們之間分配負載。
如何更新每個緩存副本？一旦出現緩存不命中，服務器都將訪問後端數據庫。無論何時發生這種情況，都可以更新緩存並將新條目傳遞給所有緩存副本。每個副本都可以通過添加新條目來更新其緩存。如果一個副本已經有這個條目，就可以忽略它。
（未完待續）
未經同意，本文禁止轉載或摘編。