摘要：舉個例子，第一個進來的鏈接發(fā)號器發(fā)號，對應(yīng)的短鏈接為，第二個進來的鏈接發(fā)號器發(fā)號，對應(yīng)的短鏈接為，以此類推。這樣一來會導(dǎo)致一條長鏈接對應(yīng)多條短鏈接的情況出現(xiàn)，不僅浪費存儲空間，又浪費發(fā)號器資源。

顧名思義，短鏈接即是長度較短的網(wǎng)址。通過短鏈接技術(shù)，我們可以將長度較長的鏈接壓縮成較短的鏈接。并通過跳轉(zhuǎn)的方式，將用戶請求由短鏈接重定向到長鏈接上去。短鏈接主要用在諸如微博，BBS等對帖子字?jǐn)?shù)有限制的網(wǎng)站，通過使用短鏈接，用戶可以把注意力放在帖子的內(nèi)容上，而不是在擔(dān)心鏈接超長的問題。這里以百度的 dwz.cn 短鏈接服務(wù)為例，我們使用百度搜索"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，統(tǒng)計了一下，這條鏈接長度為230。如此長的鏈接占據(jù)微博篇幅不說，也會影響微博的美觀度。這個時候我們可以使用百度短鏈接服務(wù)壓縮一下上面的長鏈接，壓縮后的鏈接為：http://dwz.cn/5DDXhH。可以看到，壓縮后的鏈接長度比原鏈接明顯變短了。

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

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

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

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

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

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

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