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

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

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

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

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

A：這里啰嗦一下301和302的跳轉(zhuǎn)在短鏈接服務(wù)使用場(chǎng)景下的區(qū)別：用戶第一次訪問(wèn)某個(gè)短鏈接后，如果服務(wù)器返回301狀態(tài)碼，則這個(gè)用戶在后續(xù)多次訪問(wèn)統(tǒng)一短鏈接，瀏覽器會(huì)直接請(qǐng)求跳轉(zhuǎn)地址，而不是短鏈接地址，這樣一來(lái)服務(wù)器端就無(wú)法收到用戶的請(qǐng)求。如果服務(wù)器返回302狀態(tài)碼，且告知瀏覽器不緩存短鏈接請(qǐng)求，那么用戶每次訪問(wèn)短鏈接，都會(huì)先去短鏈接服務(wù)端取回長(zhǎng)鏈接地址，然后在跳轉(zhuǎn)。從語(yǔ)義上來(lái)說(shuō)，301跳轉(zhuǎn)更為合適，因?yàn)槭怯谰锰D(zhuǎn)，不會(huì)每次都訪問(wèn)服務(wù)端，還可以減小服務(wù)端壓力。但如果使用301跳轉(zhuǎn)，服務(wù)端就無(wú)法精確搜集用戶的訪問(wèn)行為了。相反302跳轉(zhuǎn)會(huì)導(dǎo)致服務(wù)端壓力增大，但服務(wù)端此時(shí)就可精確搜集用戶的訪問(wèn)行為。基于用戶的訪問(wèn)行為，可以做一些分析，得出一些有意思的結(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

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

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