經典系統設計面試題解析：如何設計TinyURL（最終篇）

原文連接：

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,等等。

9、負載均衡器（LB）

咱們能夠在系統中的三個位置添加負載均衡器：

一、在客戶端和應用服務器之間

二、在應用服務器和數據庫服務器之間

三、在應用服務器和緩存服務器之間

開始時，咱們可使用簡單的循環（Round Robin）負載均衡器的方法，在後端服務器之間平均分配傳入的請求。這種方法很是容易實現，不會帶來任何開銷。除此以外，還有另一個好處，服務器宕機時，負載均衡器（LB）會將其從循環中取出，並中止向其發送任何流量。

使用循環負載均衡器（Round Robin LB）的方法，咱們忽略了一個問題，那就是沒有考慮服務器負載。即便服務器過載或運行緩慢，負載均衡器仍然會繼續向該服務器發送新請求。爲了解決服務器過載問題，能夠採用更智能的負載均衡器解決方案，它可以按期查詢後端服務器的負載狀況，並根據負載調整流量。

10、清除或數據庫清理

短連接條目應該永遠存在仍是應該被按期清除？若是達到用戶指定的過時時間，那對應的過時連接應如何處理？

若是咱們選擇主動搜索過時連接而後刪除它們，這種方法會給咱們的數據庫帶來很大壓力。其實，咱們能夠慢慢地刪除它們，並進行延遲清理。咱們設計的清理服務將確保只有過時的連接將被刪除，雖然一些過時連接可能不會及時清理掉，但也不會被返回給用戶。

一、當用戶試圖訪問某個過時連接時，咱們能夠刪除該連接並向用戶返回一個錯誤指令。

二、一個獨立的清理服務能夠按期運行，從存儲和緩存中刪除過時連接。此服務應該是很是輕量的，而且只能安排在預期用戶流量較低時運行。

三、咱們能夠爲每一個連接設置一個默認的過時時間（例如，兩年）。

四、過時連接刪除後，咱們能夠將key放回key-DB中以供重用。

五、咱們是否應該刪除一些長時間（好比六個月）沒有訪問過的連接？這個問題可能比較棘手。但因爲存儲愈來愈便宜，咱們能夠決定保留該連接。

11、統計數據

一個縮短URL被使用過多少次？用戶位於哪裏？等等，關於這一系列的統計數據咱們又將如何存儲呢？若是這是數據庫某行存儲的一部分並每次被更新，那麼當一個熱門的URL收到大量併發請求時，會發生什麼？

下面這些統計數據值得去跟蹤：訪問者的國家、訪問日期和時間、點擊的網頁，瀏覽器，或者訪問頁面的平臺。

12、安全與權限

用戶能夠建立私有URL或容許特定用戶訪問URL嗎？

咱們可使用數據庫中的每一個URL來存儲權限級別（公共／私有）。還能夠建立一個單獨的表來存儲有權查看特定URL的用戶ID。若是用戶沒有權限並試圖訪問URL，能夠返回錯誤（HTTP 401）。假如咱們將數據存儲在像Cassandra這樣的NoSQL列存儲(Wide-Column)數據庫中，那麼用於存儲用戶權限的數據庫表的key將是Hash值（或KGS生成的key）。而表中的列用於存儲具備查看URL權限的用戶ID。

（完）

未經贊成，本文禁止轉載或摘編。