原文鏈接：
https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR
編者注：本文以一道經典的系統設計面試題：《如何設計TinyURL》的參考答案和解析爲例，幫助讀者更深入地瞭解在系統需求分析和設計中，需要考慮的各個方面的細節。
本文將爲大家詳細講解如何設計一個類似於TinyURL的URL縮短服務。URL縮短服務提供一個非常短小的URL以代替原來的可能較長的URL，將長的URL地址縮短。
類似的服務有：http://bit.ly，goo.gl，qlink.me,等等。
九、負載均衡器（LB）
我們可以在系統中的三個位置添加負載均衡器：
1、在客戶端和應用服務器之間
2、在應用服務器和數據庫服務器之間
3、在應用服務器和緩存服務器之間
開始時，我們可以使用簡單的循環（Round Robin）負載均衡器的方法，在後端服務器之間平均分配傳入的請求。這種方法非常容易實現，不會帶來任何開銷。除此之外，還有另外一個好處，服務器宕機時，負載均衡器（LB）會將其從循環中取出，並停止向其發送任何流量。
使用循環負載均衡器（Round Robin LB）的方法，我們忽略了一個問題，那就是沒有考慮服務器負載。即使服務器過載或運行緩慢，負載均衡器仍然會繼續向該服務器發送新請求。爲了解決服務器過載問題，可以採用更智能的負載均衡器解決方案，它能夠定期查詢後端服務器的負載情況，並根據負載調整流量。
十、清除或數據庫清理
短鏈接條目應該永遠存在還是應該被定期清除？如果達到用戶指定的過期時間，那對應的過期鏈接應如何處理？
如果我們選擇主動搜索過期鏈接然後刪除它們，這種方法會給我們的數據庫帶來很大壓力。其實，我們可以慢慢地刪除它們，並進行延遲清理。我們設計的清理服務將確保只有過期的鏈接將被刪除，雖然一些過期鏈接可能不會及時清理掉，但也不會被返回給用戶。
1、當用戶試圖訪問某個過期鏈接時，我們可以刪除該鏈接並向用戶返回一個錯誤指令。
2、一個獨立的清理服務可以定期運行，從存儲和緩存中刪除過期鏈接。此服務應該是非常輕量的，並且只能安排在預期用戶流量較低時運行。
3、我們可以爲每個鏈接設置一個默認的過期時間（例如，兩年）。
4、過期鏈接刪除後，我們可以將key放回key-DB中以供重用。
5、我們是否應該刪除一些長時間（比如六個月）沒有訪問過的鏈接？這個問題可能比較棘手。但由於存儲越來越便宜，我們可以決定保留該鏈接。
十一、統計數據
一個縮短URL被使用過多少次？用戶位於哪裏？等等，關於這一系列的統計數據我們又將如何存儲呢？如果這是數據庫某行存儲的一部分並每次被更新，那麼當一個熱門的URL收到大量併發請求時，會發生什麼？
下面這些統計數據值得去跟蹤：訪問者的國家、訪問日期和時間、點擊的網頁，瀏覽器，或者訪問頁面的平臺。
十二、安全與權限
用戶可以創建私有URL或允許特定用戶訪問URL嗎？
我們可以使用數據庫中的每個URL來存儲權限級別（公共／私有）。還可以創建一個單獨的表來存儲有權查看特定URL的用戶ID。如果用戶沒有權限並試圖訪問URL，可以返回錯誤（HTTP 401）。假如我們將數據存儲在像Cassandra這樣的NoSQL列存儲(Wide-Column)數據庫中，那麼用於存儲用戶權限的數據庫表的key將是Hash值（或KGS生成的key）。而表中的列用於存儲具有查看URL權限的用戶ID。
（完）
未經同意，本文禁止轉載或摘編。