如何設計一個短鏈接服務？

平時經常受到垃圾短信或者是店家的推廣短信，短信中的鏈接一般都是短鏈接。

爲什麼這裏面的URL都是短的呢？有什麼好處呢？怎麼做到的呢？

短URL的好處

• 1. 短信和許多平臺(微博)有字數限制 ，太長的鏈接加進去都沒有辦法寫正文了
• 2. 好看。 比起一大堆不知所以的參數,短鏈接更加簡潔友好
• 3. 方便做一些統計。 你點了鏈接會有人記錄然後分析的
• 4. 安全。 不暴露訪問參數

這就是爲什麼我們現在收到的垃圾短信大多數都是短URL的原因了

那麼短URL是怎麼做到的呢?

短URL基礎原理

短URL從生成到使用分爲以下幾步：

• 1. 有一個服務，將要發送給你的長URL對應到一個短URL上。例如www.baidu.com -> www.t.cn/1
• 2. 把短URL拼接到短信等的內容上發送.
• 3. 用戶點擊短URL,瀏覽器用301/302進行重定向,訪問到對應的長URL.
• 4. 展示對應的內容.

下面介紹的是第一步，即如何將一個長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.這樣做很簡單,服務互相之間基本都不用通信,做好自己的事情就好了.