常見的短鏈結壓縮演算法有兩種，第一種是對 url 進行hash運算，在得到的hash值上做進一步運算，得到乙個較短的hash值。第二種是通過資料庫自增id或分布式key-value系統模擬發號器進行發號壓縮url。兩種方式各有優劣，hash運算簡單易實現，但是有一定的衝突率。隨著 url 壓縮數量的增加，衝突數也會增加，最終導致一部分使用者跳轉到錯誤的位址上，影響使用者體驗。而發號器發號壓縮 url 優缺點恰好和hash壓縮演算法相反，優點是不存在衝突問題。缺點是，實現上稍複雜，要協調發號器取初始號。本文對應的練手專案是基於第二種壓縮演算法實現的，下面也將對詳細分析第二種演算法。
發號策略是這樣的，當乙個新的鏈結過來時，發號器發乙個號與之對應。往後只要有新鏈結過來，發號器不停發號就好。舉個例子，第乙個進來的鏈結發號器發0號，對應的短鏈結為 xx.***/0，第二個進來的鏈結發號器發1號，對應的短鏈結為 xx.***/1，以此類推。
發號器發出的10進製號需要轉換成62進製，這樣可以大大縮短號碼轉換成字串後的長度。比如發號器發出 10,000,000,000 這個號碼，如果不轉換成62進製，直接拼接在網域名稱後面，得到這樣乙個鏈結 xx.***/10000000000。將上面的號碼轉換成62進製，結果為aoykua，長度只有6位，拼接得到的鏈結為 xx.***/aoykua。可以看得出，進製轉換後得到的短鏈結長度變短了一些。6位62進製數，對應的號碼空間為626，約等於568億。也就是說發號器可以發568億個號，這個號碼空間應該能夠滿足多數專案的需求了，所以基本上不用擔心發號器無號可發的情況。
上述是發號策略壓縮url的原理，在實際寫**的過程中還需要考慮很多細節，比如快取，儲存等。本文對應的專案基於 redis 快取，mysql 資料庫實現了乙個簡單的分布式短鏈結服務。**放到了 github 上了 -> 分布式短鏈結專案**
a：同一長鏈結，每次轉成的短鏈結不一定一樣，原因在於如果查詢快取時，如果未命中，發號器會發新號給這個鏈結。需要說明的是，快取應該快取經常轉換的熱門鏈結，假設設定快取過期時間為一小時，如果某個鏈結很活躍的話，快取查詢命中後，快取會重新整理這個鏈結的存活時間，重新計時，這個鏈結就會長久存在快取中。對於一些生僻鏈結，從存入快取開始，在存活時間內很可能不會被再次訪問，存活時間結束快取會刪除記錄。下一次轉換這個生僻鏈結，快取不命中，發號器會重新發號。這樣一來會導致一條長鏈結對應多條短鏈結的情況出現，不僅浪費儲存空間，又浪費發號器資源。那麼是否有辦法解決這個問題呢？是不是可以考慮建立乙個長鏈結-短鏈結的key-value表，將所有的長鏈結和對應的短鏈結都存入其中，這樣一來就實現了長短鏈結一一對應的了。但是想法是美好的，現實是不行的，原因在於，將所有的長鏈結-短鏈結對存入這樣的表中，本身就需要耗費大量的儲存空間，相對於生僻鏈結可能會對應多條短鏈結浪費的那點空間，這樣做顯然就得不償失了。
a：這裡囉嗦一下301和302的跳轉在短鏈結服務使用場景下的區別：使用者第一次訪問某個短鏈結後，如果伺服器返回301狀態碼，則這個使用者在後續多次訪問統一短鏈結，瀏覽器會直接請求跳轉位址，而不是短鏈結位址，這樣一來伺服器端就無法收到使用者的請求。如果伺服器返回302狀態碼，且告知瀏覽器不快取短鏈結請求，那麼使用者每次訪問短鏈結，都會先去短鏈結服務端取回長鏈結位址，然後在跳轉。從語義上來說，301跳轉更為合適，因為是永久跳轉，不會每次都訪問服務端，還可以減小服務端壓力。但如果使用301跳轉，服務端就無法精確蒐集使用者的訪問行為了。相反302跳轉會導致服務端壓力增大，但服務端此時就可精確蒐集使用者的訪問行為。基於使用者的訪問行為，可以做一些分析，得出一些有意思的結論。比如可以根據使用者ip位址得出使用者區域分布情況，根據user-agent訊息頭分析出使用者使用不同的作業系統以及瀏覽器比例等等。
本作品採用知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議進行許可。
短鏈結演算法收集與分析
yun.io 如何實現呢，大概有三個步驟 1 定義乙個url對映演算法，可以將長的url對映成短字串 2 使用乙個儲存 資料庫？nosql？來儲存完成的對映 3 實現自己的url對映演算法 一般來說，第三步是我們比較頭疼的，如何將乙個長的url字串，對映成乙個較短的字串呢。我總結了三種辦法 普通實現...
php mysql 短鏈結 PHP生成短鏈結案例
首先我們建立的檔案有三個,api檔案 生成短連線呼叫 index檔案 訪問短連線時跳轉使用 config檔案 連線資料庫用的 呼叫方法 網域名稱 api.php?url nginx規則 location elseelseelseelse echo json encode array code 201...
長鏈結轉短鏈結
將長鏈結轉化成短鏈結 風之子 2012 短鏈 短位址 short url 杭州.mark 演算法大致如下 1 將長 md5生成32位簽名串,分為4段,每段8個位元組 2 對這四段迴圈處理,取8個位元組,將他看成16進製制串與0x3fffffff 30位1 與操作,即超過30位的忽略處理 3 這30位...