1. 什麼是短鏈接
顧名思義，短鏈接即是長度較短的網址。通過短鏈接技術，我們可以將長度較長的鏈接壓縮成較短的鏈接。並通過跳轉的方式，將用戶請求由短鏈接重定向到長鏈接上去。短鏈接主要用在諸如微博，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。可以看到，壓縮後的鏈接長度比原鏈接明顯變短了。
百度短地址服務
2. 常見的短鏈接壓縮算法
常見的短鏈接壓縮算法有兩種，第一種是對 URL 進行hash運算，在得到的hash值上做進一步運算，得到一個較短的hash值。第二種是通過數據庫自增ID或分佈式key-value系統模擬發號器進行發號壓縮URL。兩種方式各有優劣，hash運算簡單易實現，但是有一定的衝突率。隨着 URL 壓縮數量的增加，衝突數也會增加，最終導致一部分用戶跳轉到錯誤的地址上，影響用戶體驗。而發號器發號壓縮 URL 優缺點恰好和hash壓縮算法相反，優點是不存在衝突問題。缺點是，實現上稍複雜，要協調發號器取初始號。本文對應的練手項目是基於第二種壓縮算法實現的，下面也將對詳細分析第二種算法。
3. 使用發號策略壓縮URL
發號策略是這樣的，當一個新的鏈接過來時，發號器發一個號與之對應。往後只要有新鏈接過來，發號器不停發號就好。舉個例子，第一個進來的鏈接發號器發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進制數，對應的號碼空間爲626，約等於568億。也就是說發號器可以發568億個號，這個號碼空間應該能夠滿足多數項目的需求了，所以基本上不用擔心發號器無號可發的情況。 上述是發號策略壓縮URL的原理，在實際寫代碼的過程中還需要考慮很多細節，比如緩存，存儲等。本文對應的項目基於 Redis 緩存，MySQL 數據庫實現了一個簡單的分佈式短鏈接服務。代碼放到了 Github 上了 -> 分佈式短鏈接項目代碼
4. 幾個細節問題
Q：同一長鏈接，每次轉成的短鏈接是否一樣
A：同一長鏈接，每次轉成的短鏈接不一定一樣，原因在於如果查詢緩存時，如果未命中，發號器會發新號給這個鏈接。需要說明的是，緩存應該緩存經常轉換的熱門鏈接，假設設定緩存過期時間爲一小時，如果某個鏈接很活躍的話，緩存查詢命中後，緩存會刷新這個鏈接的存活時間，重新計時，這個鏈接就會長久存在緩存中。對於一些生僻鏈接，從存入緩存開始，在存活時間內很可能不會被再次訪問，存活時間結束緩存會刪除記錄。下一次轉換這個生僻鏈接，緩存不命中，發號器會重新發號。這樣一來會導致一條長鏈接對應多條短鏈接的情況出現，不僅浪費存儲空間，又浪費發號器資源。那麼是否有辦法解決這個問題呢？是不是可以考慮建立一個長鏈接-短鏈接的key-value表，將所有的長鏈接和對應的短鏈接都存入其中，這樣一來就實現了長短鏈接一一對應的了。但是想法是美好的，現實是不行的，原因在於，將所有的長鏈接-短鏈接對存入這樣的表中，本身就需要耗費大量的存儲空間，相對於生僻鏈接可能會對應多條短鏈接浪費的那點空間，這樣做顯然就得不償失了。
Q：短鏈接使用301跳轉還是302跳轉
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