1.前言

　　長地址：

　　　　就是頁面請求實際的地址。如知乎某文章https://www.zhihu.com/question/20103344

　　短地址：

　　　　特定長地址縮短后對應的長度很短的地址，基本上可以理解為一一對應關系

　　　　如https://www.zhihu.com/question/20103344的短地址為 http://dwz.date/am7a

　　備注：

　　　　上述地址是由新浪地址轉換平臺提供的，對于同一個長地址，不同的轉換平臺生成的短地址不一樣，

　　　　同一個平臺不同時間長成的短地址也可能不一樣

2.使用場景

　　微博上發送新微博內容時，限制字數為140字，如果需要分享鏈接，那么很長的鏈接會導致內容篇幅縮小，而且url本身也可能超過140個字，所以如果把地址轉換為短地址，那么用戶輸入短地址，看到的是和輸入長地址一樣的頁面信息，那么用戶體驗會變好。

　　發送推廣短信時超出70字算兩條短信，費用增加，長鏈接也影響用戶體驗

　　綜上

　　　　在特定場景下，需要能夠把長連接轉換為短鏈接

　　　　用戶輸入短鏈接的效果和長連接一樣（瀏覽器后臺重定向）

　　　　短鏈接需要長期有效（或者一定時間內，如1天內有效）

　　　　對于同樣的長鏈接，生成的短鏈接需要一樣（或者在一定時間內一樣）

3.實現必要條件（基于本博客所用方案而言的必要條件）

　　1.有一個獨立的域名系統，用于拼接完整的短鏈接，以后后續反查長鏈接地址

　　2.一個id發號器（生成樹數字保持唯一），如數據庫的自增序列

4.實現方案

　　a.將長鏈接字符串插入數據庫，使用sequence遞增序列作為主鍵，然后返回主鍵id

　　或者是先從發號器取出一個新的id，插入id和長鏈接字符串（兩個字段，且id為主鍵）

　　b.將主鍵id進行62進制編碼（10數字+26大寫字母+26小寫字母，一般url用這些表示）

　　c.使用自身域名信息+62進制字符串拼接為完整的url，然后返回

　　解析：

　　　　客戶請求短鏈接時，時間是尋址短鏈接域名發送到我們的系統上，

　　　　然后根據鏈接后面的url后綴，轉換為10進制，去數據庫查詢這個主鍵，找出長鏈接，

　　　　然后返回給客戶端，且返回碼為301/302（瀏覽器會自動重定向到長鏈接地址，用戶無感知）.

5.優化方案

　　上面有兩個問題未解決：

　　　　a.發號器可能會成為瓶頸

　　　　b.對于同樣的長鏈接，生成的短鏈接不一樣

　　解決辦法：

　　　　a.發號器問題

　　　　　　可以多用幾個發號器，各自發號不重復即可。

　　　　　　如10個發號器，則發號尾號是1，2，3，4，5，6，7，8，9，0

　　　　　　即發號進制等于發號器的數量，如果發號器只有一個，那么每次發號數增加1.

　　　　b. 短鏈接不一樣的問題

　　　　　　方案一：內存存放LinkedHashMap，key為長鏈接，value為短鏈接，

　　　　　　考慮到內存問題，那么只能存放一定數量的鍵值對，使用LRU進行驅逐。

　　　　　　這樣，在一定時間內，某個長鏈接生成的短鏈接一直不變。

　　　　　　方案二：（考慮到要求長鏈接對應的短鏈接要永久一樣）

　　　　　　存入數據庫時，除了唯一id和長鏈接地址外，使用長鏈接生成64位hashcode，然后一并存入數據庫，并且添加索引

　　　　　　下次插入數據庫之前，先查詢hashcode列是否有這個值，有的話則取出比較value是否相等，

　　　　　　這里可能是hash沖突，實際上不是同一個長鏈接，但是使用64位hashcode的話，沖突概率會小很多，

　　　　　　這里使用hashcode做索引，而不是直接使用長鏈接本身，是考慮到長鏈接比較長，作為索引的話，會導致索引層級加深，需要增加額外的磁盤尋址

6.產品舉例

新浪：http://sina.lt/
百度：http://dwz.cn/
0x3：http://0x3.me/
MRW：http://mrw.so/

　　　　新浪長地址轉短地址，使用結果如下：

　　　　https://www.zhihu.com/question/20103344 生成的短地址為：am7a

　　　　

　　　　

　　　　　　https://www.kanzhun.com/employee/gsl1194828/1587907702/生成的短地址為：am7c

　　

　　使用短鏈接去請求頁面：

　　　　

總結

以上是生活随笔為你收集整理的长地址URL转短地址URL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。