原文地址：https://www.itcodemonkey.com/article/8721.html 一、前言 前幾天整理面試題的時候，有一道試題是《如何將一個很長的URL轉換為一個短的URL，並實現他們之間的相互轉換？》，現在想起來這是一個絕對不簡單的問題，需要考慮很多方面，今天和大家一起學習研究一下！

短網址：顧名思義，就是將長網址縮短到一個很短的網址，使用者訪問這個短網址可以重定向到原本的長網址（也就是還原的過程）。這樣可以達到易於記憶、轉換的目的，常用於有字數限制的微博、二維碼等等場景。

關於短URL的使用場景，舉個簡單的例子來說明一下，看一下業務中使用短URL的重要性！

二、短地址使用場景

1、新浪微博

這是因為微博限制字數為140字一條，那麼如果我們需要發一些連結上去，但是這個連結非常的長，以至於將近要佔用我們內容的一半篇幅，這肯定是不能被允許的或者說使用者體驗很差的，所以短網址應運而生了，短網址這種服務可以說是在微博出現之後才流行開來的！往下看：

（1）首先，我先發一條微博帶有一個URL地址：

（2）然後，看他轉換之後顯示的效果是什麼樣子的哪？

（3）檢視對應頁面元素的HTML原始碼如下：

2、短網址二維碼

網址在轉換成短網址時，也可以生成相應的短網址二維碼，短網址二維碼的應用，二維碼核心解決的是跨平臺、跨現實的資料傳輸問題；而且二維碼跟應用場景結合之後，所能解決的問題會越來越多。

（1）短網址二維碼相比短連結更方便，能少輸入，儘量少輸入，哪怕只是少點一下鍵盤，都是有意義的。

（2）二維碼只是掃描一個簡單的連結，開啟的卻是一個世界。想象一下，用手機購買售貨機裡商品，二維碼掃描是略快於從用手機找到該售貨機並找到該商品的，而且這種操作相對於搜尋/查詢而言不是更優雅嗎?

（3）所有商超裡面的商品，都是使用條碼來確定商品的唯一性的，去買單的時候都是掃描條碼。試想，如果裡面加入了更多產品的生產日期、廠家、流轉途徑、原材料等等資訊，是不是厲害了呢?特別是針對食品資訊的可追溯上，二維碼應用場景更廣泛。

三、短地址的好處

除了上述場景中，我們將長地址轉換為短地址的使用場景的優點（壓縮URL長度）之外，短地址還具有很多實際場景中的優點，例如：

（1）節省網址長度，便於社交化傳播，一個是讓URL更短小，傳播更方便，尤其是URL中有中文和特殊字元，短網址解決很長的URL難以記憶不利於傳播的問題；

（2）短網址在我們專案裡可以很好的對開放以及對URL進行管理。有一部分網址可以會涵蓋性、暴力、廣告等資訊，這樣我們可以通過使用者的舉報，完全管理這個連線將不出現在我們的應用中，對同樣的URL通過加密演算法之後，得到的地址是一樣的；

（3）方便後臺跟蹤點選量、地域分佈等使用者統計。我們可以對一系列的網址進行流量，點選等統計，挖掘出大多數使用者的關注點，這樣有利於我們對專案的後續工作更好的作出決策；

（4）規避關鍵詞、域名遮蔽手段、隱藏真實地址，適合做付費推廣連結；

（5）當你看到一個淘寶的寶貝連線後面是200個“e7x8bv7c8bisdj”這樣的字元的時候，你還會覺得舒服嗎。更何況微博字數只有140字，微博或簡訊裡，字數不夠，你用條短網址就能幫你騰出很多空間來；

四、短網址服務提供平臺

目前，國內網又很多提供短地址服務的平臺，例如：

等等還有很多，這個可以搜尋一下就會有很多！但是一個注意的是，如果使用某一個平臺的短地址服務，一定要保證長期可靠的服務，不然一段時間失效了，我們以前已經轉換的URL就完了！

這裡以百度例，將我們上述部落格的地址轉換為短地址如下所示：

當然，對於我們的業務來說，如果自己可以提供自己的短URL服務那才是更好的，不需要受制於人！（中國晶片需要崛起！！！）

五、關於如何生成短地址URL的討論

關於短地址URL如何生成方式的，網上有很多方式，有基於對映的，有基於Hash的，有基於簽名的，但是總的來說並不能滿足絕大部分場景的使用，或者說是一種錯誤的設計方式。這裡不再重複造輪子！以下是知乎使用者iammutex關於該問題的探討，截圖過來和大家一起學習一下：

六、生成短地址URL需要注意的

看到上述知乎使用者iammutex關於如何正確生成短地址URL的探討，我們知道了，可以通過發號器的方式正確的生成短地址，生成演算法設計要點如下：

（1）利用放號器，初始值為0，對於每一個短連結生成請求，都遞增放號器的值，再將此值轉換為62進位制（a-zA-Z0-9），比如第一次請求時放號器的值為0，對應62進製為a，第二次請求時放號器的值為1，對應62進製為b，第10001次請求時放號器的值為10000，對應62進製為sBc。

（2）將短連結伺服器域名與放號器的62進位制值進行字串連線，即為短連結的URL，比如：t.cn/sBc。

（3）重定向過程：生成短連結之後，需要儲存短連結到長連結的對映關係，即sBc -> URL，瀏覽器訪問短連結伺服器時，根據URL Path取到原始的連結，然後進行302重定向。對映關係可使用K-V儲存，比如Redis或Memcache。

七、生成短地址之後如何跳轉哪？

對於該部分的討論，我們可以認為他是整個互動的流程，具體的流程細節如下：

（4）瀏覽器重新向https://blog.csdn.net/xlgen157387/article/details/79863301傳送請求；

（5）返回響應；

八、短地址發號器優化方案

1、演算法優化

採用以上演算法，如果不加判斷，那麼即使對於同一個原始URL，每次生成的短連結也是不同的，這樣就會浪費儲存空間（因為需要儲存多個短連結到同一個URL的對映），如果能將相同的URL對映成同一個短連結，這樣就可以節省儲存空間了。主要的思路有如下兩個：

方案1：查表

每次生成短連結時，先在對映表中查詢是否已有原始URL的對映關係，如果有，則直接返回結果。很明顯，這種方式效率很低。

方案2：使用LRU本地快取，空間換時間

使用固定大小的LRU快取，儲存最近N次的對映結果，這樣，如果某一個連結生成的非常頻繁，則可以在LRU快取中找到結果直接返回，這是儲存空間和效能方面的折中。

2、可伸縮和高可用

如果將短連結生成服務單機部署，缺點一是效能不足，不足以承受海量的併發訪問，二是成為系統單點，如果這臺機器宕機則整套服務不可 用，為了解決這個問題，可以將系統叢集化，進行“分片”。

在以上描述的系統架構中，如果發號器用Redis實現，則Redis是系統的瓶頸與單點，因此，利用資料庫分片的設計思想，可部署多個發號器例項，每個例項負責特定號段的發號，比如部署10臺Redis，每臺分別負責號段尾號為0-9的發號，注意此時發號器的步長則應該設定為10（例項個數）。

另外，也可將長連結與短連結對映關係的儲存進行分片，由於沒有一箇中心化的儲存位置，因此需要開發額外的服務，用於查詢短連結對應的原始連結的儲存節點，這樣才能去正確的節點上找到對映關係。

九、如何用程式碼實現短地址

說到這裡終於說到重點了，很多小夥伴已經按捺不住了，不好意思讓大家失望了，這只是一片簡單的文章，並不能把這麼繁雜的一個系統演示清楚！秉著不要重複造輪子的原則，這裡給出一個為數不多還算可以的實現短地址的開源專案：urlshorter

注意：urlshorter本身還是基於隨機的方式生成短地址的，並不算是一個短地址發號器，因此會有效能問題和衝突的出現，和知乎使用者iammutex 描述的實現方式還是有區別的！而關於短地址發號器的方式目前還沒有找到更好的開源專案可供參考！

十、總結

到此為止，我們一起學習了什麼是短地址，短地址的優點，如何選擇一種正確的方式來實現我們的短地址，以及在碼雲上找到的一個還算可以的短地址生成專案，相信此時的你能夠有一個更好的瞭解！