短連接原理

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進制數，對應的號碼空間爲62⁶，約等於568億。也就是說發號器能夠發568億個號，這個號碼空間應該可以知足多數項目的需求了，因此基本上不用擔憂發號器無號可發的狀況。
  上述是發號策略壓縮URL的原理，實際在寫代碼的過程當中還須要考慮不少細節，好比緩存，存儲等。本文對應的項目使用的緩存是 Guava 工具包中提供的緩存模塊，數據庫使用的是 MySQL。基於上述兩個工具以及其餘一些第三方庫，項目實現了URL壓縮，還原以及跳轉功能三個基礎的功能。項目代碼放到了 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

本文在知識共享許可協議 4.0 下發布，轉載請註明出處
做者：code4fun
爲了得到更好的閱讀體驗，請移步至本人的我的博客：http://www.coolblog.xyz

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