摘要：舉個例子，第一個進來的鏈接發號器發號，對應的短鏈接為，第二個進來的鏈接發號器發號，對應的短鏈接為，以此類推。這樣一來會導致一條長鏈接對應多條短鏈接的情況出現，不僅浪費存儲空間，又浪費發號器資源。

顧名思義，短鏈接即是長度較短的網址。通過短鏈接技術，我們可以將長度較長的鏈接壓縮成較短的鏈接。并通過跳轉的方式，將用戶請求由短鏈接重定向到長鏈接上去。短鏈接主要用在諸如微博，BBS等對帖子字數有限制的網站，通過使用短鏈接，用戶可以把注意力放在帖子的內容上，而不是在擔心鏈接超長的問題。這里以百度的 dwz.cn 短鏈接服務為例，我們使用百度搜索"hello world"，鏈接為https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=0&rsv_idx=1&tn=baidu&wd=hello%20world&rsv_pq=8487bffe00068c60&rsv_t=a9e0f5b6haiMQwAi4N2y8PHDv37rM6sjjKrHJb6KdMGg2dQuUjAnmSEnXtE&rqlang=cn&rsv_enter=1&rsv_sug3=10&rsv_sug1=9&rsv_sug7=100，統計了一下，這條鏈接長度為230。如此長的鏈接占據微博篇幅不說，也會影響微博的美觀度。這個時候我們可以使用百度短鏈接服務壓縮一下上面的長鏈接，壓縮后的鏈接為：http://dwz.cn/5DDXhH。可以看到，壓縮后的鏈接長度比原鏈接明顯變短了。

常見的短鏈接壓縮算法有兩種，第一種是對 URL 進行hash運算，在得到的hash值上做進一步運算，得到一個較短的hash值。第二種是通過數據庫自增ID或分布式key-value系統模擬發號器進行發號壓縮URL。兩種方式各有優劣，hash運算簡單易實現，但是有一定的沖突率。隨著 URL 壓縮數量的增加，沖突數也會增加，最終導致一部分用戶跳轉到錯誤的地址上，影響用戶體驗。而發號器發號壓縮 URL 優缺點恰好和hash壓縮算法相反，優點是不存在沖突問題。缺點是，實現上稍復雜，要協調發號器取初始號。本文對應的練手項目是基于第二種壓縮算法實現的，下面也將對詳細分析第二種算法。

發號策略是這樣的，當一個新的鏈接過來時，發號器發一個號與之對應。往后只要有新鏈接過來，發號器不停發號就好。舉個例子，第一個進來的鏈接發號器發0號，對應的短鏈接為 xx.xxx/0，第二個進來的鏈接發號器發1號，對應的短鏈接為 xx.xxx/1，以此類推。
發號器發出的10進制號需要轉換成62進制，這樣可以大大縮短號碼轉換成字符串后的長度。比如發號器發出 10,000,000,000 這個號碼，如果不轉換成62進制，直接拼接在域名后面，得到這樣一個鏈接 xx.xxx/10000000000。將上面的號碼轉換成62進制，結果為AOYKUa，長度只有6位，拼接得到的鏈接為 xx.xxx/AOYKUa。可以看得出，進制轉換后得到的短鏈接長度變短了一些。6位62進制數，對應的號碼空間為62⁶，約等于568億。也就是說發號器可以發568億個號，這個號碼空間應該能夠滿足多數項目的需求了，所以基本上不用擔心發號器無號可發的情況。
上述是發號策略壓縮URL的原理，在實際寫代碼的過程中還需要考慮很多細節，比如緩存，存儲等。本文對應的項目基于 Redis 緩存，MySQL 數據庫實現了一個簡單的分布式短鏈接服務。代碼放到了 Github 上了 -> 分布式短鏈接項目代碼

A：同一長鏈接，每次轉成的短鏈接不一定一樣，原因在于如果查詢緩存時，如果未命中，發號器會發新號給這個鏈接。需要說明的是，緩存應該緩存經常轉換的熱門鏈接，假設設定緩存過期時間為一小時，如果某個鏈接很活躍的話，緩存查詢命中后，緩存會刷新這個鏈接的存活時間，重新計時，這個鏈接就會長久存在緩存中。對于一些生僻鏈接，從存入緩存開始，在存活時間內很可能不會被再次訪問，存活時間結束緩存會刪除記錄。下一次轉換這個生僻鏈接，緩存不命中，發號器會重新發號。這樣一來會導致一條長鏈接對應多條短鏈接的情況出現，不僅浪費存儲空間，又浪費發號器資源。那么是否有辦法解決這個問題呢？是不是可以考慮建立一個長鏈接-短鏈接的key-value表，將所有的長鏈接和對應的短鏈接都存入其中，這樣一來就實現了長短鏈接一一對應的了。但是想法是美好的，現實是不行的，原因在于，將所有的長鏈接-短鏈接對存入這樣的表中，本身就需要耗費大量的存儲空間，相對于生僻鏈接可能會對應多條短鏈接浪費的那點空間，這樣做顯然就得不償失了。

A：這里啰嗦一下301和302的跳轉在短鏈接服務使用場景下的區別：用戶第一次訪問某個短鏈接后，如果服務器返回301狀態碼，則這個用戶在后續多次訪問統一短鏈接，瀏覽器會直接請求跳轉地址，而不是短鏈接地址，這樣一來服務器端就無法收到用戶的請求。如果服務器返回302狀態碼，且告知瀏覽器不緩存短鏈接請求，那么用戶每次訪問短鏈接，都會先去短鏈接服務端取回長鏈接地址，然后在跳轉。從語義上來說，301跳轉更為合適，因為是永久跳轉，不會每次都訪問服務端，還可以減小服務端壓力。但如果使用301跳轉，服務端就無法精確搜集用戶的訪問行為了。相反302跳轉會導致服務端壓力增大，但服務端此時就可精確搜集用戶的訪問行為。基于用戶的訪問行為，可以做一些分析，得出一些有意思的結論。比如可以根據用戶IP地址得出用戶區域分布情況，根據User-Agent消息頭分析出用戶使用不同的操作系統以及瀏覽器比例等等。

https://www.zhihu.com/question/29270034/answer/46446911
http://blog.csdn.net/xyz_lmn/article/details/8057270
http://blog.csdn.net/beiyeqingteng/article/details/7706010

本文在知識共享許可協議 4.0 下發布，轉載需在明顯位置處注明出處
作者：coolblog
同步發布地址：http://www.coolblog.xyz

本作品采用知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議進行許可。