為什麼有的網站連結這麼短？

👉 這是一個或許對你有用的社群

🐱 一對一交流/面試小冊/簡歷最佳化/求職解惑，歡迎加入「芋道快速開發平臺」知識星球。下面是星球提供的部分資料：

《專案實戰（影片）》：從書中學，往事上“練”

《網際網路高頻面試題》：面朝簡歷學習，春暖花開

《架構 x 系統設計》：摧枯拉朽，掌控面試高頻場景題

《精進 Java 學習指南》：系統學習，網際網路主流技術棧

《必讀 Java 原始碼專欄》：知其然，知其所以然

👉這是一個或許對你有用的開源專案

國產 Star 破 10w+ 的開源專案，前端包括管理後臺 + 微信小程式，後端支援單體和微服務架構。

功能涵蓋 RBAC 許可權、SaaS 多租戶、資料許可權、商城、支付、工作流、大屏報表、微信公眾號、ERP、CRM、AI 大模型等等功能：

Boot 多模組架構：https://gitee.com/zhijiantianya/ruoyi-vue-pro

Cloud 微服務架構：https://gitee.com/zhijiantianya/yudao-cloud

影片教程：https://doc.iocoder.cn

【國內首批】支援 JDK 17/21 + SpringBoot 3.3、JDK 8/11 + Spring Boot 2.7 雙版本

來源：孤獨煙

引言

今天下午，同事在廁所裡排隊等坑的時候(人多坑少)。想象一下一個場景，我正在一邊排隊，一邊拿著手機撩妹。前面一個同事，拿著手機簡訊轉過頭來和我聊天。

於是，我們就開始討論下面這種短連結的實現原理(沒錯，上廁所也不忘學習！)。

點選其中短連結後，我們會跳到如下地址http://h5.dangdang.com/mix_20191015_or4x本文，我們來討論一下其實現原理！

基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能

專案地址：https://github.com/YunaiV/ruoyi-vue-pro

影片教程：https://doc.iocoder.cn/video/

正文

需求緣起

這裡說一下，為什麼需要短連結？這個簡單，比如大家發微博有字數限制

如果 URL 地址過長，顯然可以寫的關鍵字就越少!

再比如發簡訊如果簡訊內容過長，那麼一條簡訊就要拆成兩條發，浪費錢!

因此採用短連結，不僅節約資源，還十分美觀!

請求流程

首先，我們先看看噹噹的短連結http://dwz.win/nXR

它是由兩個部分組成

http://dwz.win:短連結系統的域名地址
nXR:請求引數

請求http://dwz.win/nXR地址後，返回狀態如下所示

於是，我們可以推斷出，敲下http://dwz.win/nXR地址後，發生了什麼呢？

這裡渣渣煙就要多嘴一句了。上圖所示短連結系統，返回的狀態可以為 301 或者 302，只是噹噹網用的是 301。

這裡我要說一下，大家應該明白30X狀態，在 HTTP 協議中，代表的是重定向的狀態。那麼301和302區別在哪呢，繼續往下看。

301 代表什麼？

301 代表的是永久重定向。什麼意思呢? 對於 GET 請求, 301 跳轉會預設被瀏覽器 cache。也就是說，使用者第一次訪問某個短連結後，如果伺服器返回 301 狀態碼，則這個使用者在後續多次訪問同一短連結地址，瀏覽器會直接請求跳轉地址，而不會再去短連結系統上取！

這麼做優點很明顯，降低了伺服器壓力，但是無法統計到短連結地址的點選次數。

302 代表什麼？

302 代表的是臨時定向。什麼意思呢? 對於 GET 請求, 302 跳轉預設不會被瀏覽器快取，除非在 HTTP 響應中透過 Cache-Control 或 Expires 暗示瀏覽器快取。因此，使用者每次訪問同一短連結地址，瀏覽器都會去短連結系統上取。

這麼做的優點是，能夠統計到短地址被點選的次數了。但是伺服器的壓力變大了。

下面說最關鍵的一段，怎麼將http://h5.dangdang.com/mix_20191015_or4x壓縮為nXR字元

演算法原理

首先呢，我們需要一張表來儲存，長短連結間的對映關係。表結構如下

列名	說明
id	BIGINT,自增主鍵
url	長地址，也就是需要跳轉的原地址

好的，假設我們此時表裡的資料如下

id	url
1	http://h5.dangdang.com/mix_20191015_or4x
2	http://h5.dangdang.com/mix_20191102_ad3x

我們此時拿自增 id 作為短連結的 key。假設域名http://dwz.win是短連結系統，也就是說請求:

(1)http://dwz.win/1會跳轉http://h5.dangdang.com/mix_20191015_or4x;
(2)http://dwz.win/2會跳轉http://h5.dangdang.com/mix_20191102_ad3x;

這麼做，也不是不行，有兩個缺點你要評估能不能接受！

(1)如果資料比較大，比如幾百億，你的 url 地址依然過長
(2)你的資料具有規律性，別人用一個簡單的指令碼就可以遍歷出你的跳轉地址！

為了解決上面的兩個缺點，我們增加一個列，用來儲存 key 值。此時表結構如下

列名	說明
id	BIGINT,自增主鍵
key	短串，需要加唯一索引
url	長地址，也就是需要跳轉的原地址

我們為了縮短 id 的長度呢，一般可以這麼做。由於我們的短連結是由 a-z、A-Z 和 0-9 共 62 個字元可以選擇。因此，我們可以將十進位制的數字 id，轉換為一個 62 進位制的數，例如 201314 就可以轉換為 Qn0。演算法如下

privatestaticfinal
 String BASE = 
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
;
publicstatic String toBase62(long num)
{

    StringBuilder sb = 
new
 StringBuilder();
do
 {
int
 i = (
int
) (num % 
62
);

        sb.append(BASE.charAt(i));

        num /= 
62
;

    } 
while
 (num > 
0
);
return
 sb.reverse().toString();

}