面試官：你平時是否留意過一些垃圾短信中包含短鏈接？
候選人：有的，就像下面這樣！
面試官：
爲什麼選擇這種短鏈接這種方式？
有什麼好處？
如果讓你實現一個短鏈接的生成服務，你會怎麼設計？
這篇文章，我們就來聊聊上述問題！
首先，短url的好處:
短. 短信和許多平臺(微博)有字數限制,太長的鏈接加進去都沒有辦法寫正文了.
好看. 比起一大堆不知所以的參數,短鏈接更加簡潔友好.
方便做一些統計.你點了鏈接會有人記錄然後分析的.
安全. 不暴露訪問參數.
這就是爲什麼我們現在收到的垃圾短信大多數都是短URL的原因了.
那麼短URL是怎麼做到的呢?
短URL基礎原理
短URL從生成到使用分爲以下幾步.
有一個服務,將要發送給你的長URL對應到一個短URL上.例如 www.baidu.com->www.t.cn/1
把短url拼接到短信等的內容上發送.
用戶點擊短URL,瀏覽器用301/302進行重定向,訪問到對應的長URL.
展示對應的內容.
那麼，如何將一個長URL對應到短URL上呢？
服務設計
如果你在往長短URL真實的對應關係上想,那麼就走遠了.
最理想的情況: 我們用一種算法,對每一個長URL,唯一的轉換成短URL.還能保持反向轉換的能力.
但是這是不可能的,如果有這樣的算法,世界上的所有壓縮算法都可以原地去世了.
正確的思路是建立一個發號器,每次有一個新的長URL進來,我們就增加一,並且將新的數值返回.第一個來的url返回"www.x.cn/0",第二個返回"www.x.cn/1".
接下來以QA形式寫幾個小問題:
對應關係如何存儲?
這個對應數據肯定是要落盤的,不能每次系統重啓就重新排號,所以可以採用mysql等數據庫來存儲.而且如果數據量小且qps低,直接使用數據庫的自增主鍵就可以實現.
如何保證長短鏈接一一對應?
按照上面的發號器策略,是不能保證長短鏈接的一一對應的,你連續用同一個URL請求兩次,結果值都是不一樣的.
爲了實現長短鏈接一一對應,我們需要付出很大的空間代價,尤其是爲了快速響應,我們可以需要在內存中做一層緩存,這樣子太浪費了.
但是可以實現一些變種的,來實現部分的一一對應, 比如將最近/最熱門的對應關係存儲在K-V數據庫中,這樣子可以節省空間的同時,加快響應速度.
短URL的存儲
我們返回的短URL一般是將數字轉換成32進制,這樣子可以更加有效的縮短URL長度
那麼32進制的數字對計算機來說只是字符串,怎麼存儲呢?直接存儲字符串對等值查找好找,對範圍查找等太不友好了.
其實可以直接存儲10進制的數字,這樣不僅佔用空間少,對查找的支持較好,同時還可以更加方便的轉換到更多/更少的進制來進一步縮短URL.
高併發
如果直接存儲在MySQL中,當併發請求增大,對數據庫的壓力太大,可能會造成瓶頸,這時候是可以有一些優化的.
緩存
上面保證長短鏈接一一對應中也提到過緩存,這裏我們是爲了加快程序處理速度.
可以將熱門的長鏈接(需要對長鏈接進來的次數進行計數),最近的長鏈接(可以使用redis保存最近一個小時的)等等進行一個緩存,保存在內存中或者類似redis的內存數據庫中
如果請求的長URL命中了緩存,那麼直接獲取對應的短URL進行返回,不需要再進行生成操作.
批量發號
每一次發號都需要訪問一次MySQL來獲取當前的最大號碼,並且在獲取之後更新最大號碼,這個壓力是比較大的.
我們可以每次從數據庫獲取10000個號碼,然後在內存中進行發放,當剩餘的號碼不足1000時,重新向MySQL請求下10000個號碼.在上一批號碼發放完了之後,批量進行寫入.
這樣可以將對數據庫持續的操作移到代碼中進行,並且異步進行獲取和寫入操作,保證服務的持續高併發.
分佈式
上面設計的系統是有單點的,那就是發號器是個單點,容易掛掉.
可以採用分佈式服務,分佈式的話,如果每一個發號器進行發號之後都需要同步給其他發號器,那未必也太麻煩了.
換一種思路,可以有兩個發號器,一個發單號,一個發雙號,發號之後不再是遞增1,而是遞增2.
類比可得,我們可以用1000個服務,分別發放0-999尾號的數字,每次發號之後遞增1000.這樣做很簡單,服務互相之間基本都不用通信,做好自己的事情就好了.
實現
由於我懶得寫JDBC代碼,更懶得弄Mybatis,所以代碼中使用到MySQL的地方都使用了Redis.