騰訊女后端設計了一套短鏈系統，當場就想給她 offer！

作者：猿java 2025-04-27 10:10:04

開發后端

本文通過一個客服評價的短信開始，分析了短鏈的構成，短鏈跳轉的原理，同時也給出了業內的一些實現算法，以及一些架構上的建議。

Hi，你好，我是猿java

如下圖，對于這種客評短信，相信大家并不陌生，通過點擊短信里“藍色字體”跳轉到一個具體的網頁。

其實，上圖中那串藍色字符，有個美麗的專業術語：短鏈。它可以是一個 URL地址，也可以是一個二維碼。而整個跳轉流程的背后是一套完整的短鏈系統，因此，今天我們來一起分析：如何設計一套高性能短鏈系統。

一、為什么需要短鏈？

存在即合理，這里列舉三個主要原因。

(1) 相對安全

短鏈不容易暴露訪問參數，生成方式可以完全迎合短信平臺的規則，能夠有效地規避關鍵詞、域名屏蔽等風險，而原始 URL地址，很可能因為包含特殊字符被短信系統誤判，導致鏈接無法跳轉。

(2) 美觀

對于精簡的文字，似乎更符合美學觀念，不太讓人產生反感。

(3) 平臺限制

短信發送平臺有字數限制，在整條短信字數不變的前提下，把鏈接縮短，其他部分的文字描述就能增加，這樣似乎更能達到該短信的實際目的（比如，營銷）。

二、短鏈的組成

如下圖，短鏈的組成通常包含兩個部分：域名 + 隨機碼

短鏈的域名最好和其他業務域名分開，而且要盡量簡短，可以不具備業務含義（比如：xyz.com），因為短鏈大部分是用于營銷，可能會被三方平臺屏蔽。

短鏈的隨機碼需要全局唯一，建議 10位以下。

三、短鏈的跳轉原理

首先，我們先看一個短鏈跳轉的簡單例子，如下代碼，定義了一個 302重定向的代碼示例：

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.servlet.view.RedirectView;

@Controller
publicclass RedirectController {

@GetMapping("/{shortCode}")
public RedirectView redirect(@PathVariable String shortCode) {
    String destUrl = "https://yuanjava.com";
    // destUrl = getDestUrlByShortCode(shortCode); //真實的業務邏輯
    returnnew RedirectView(destUrl);
  }

接著，在瀏覽器訪問短鏈”http://127.0.0.1:8080/s2TYdWd” 后，請求會被重定向到 https://yuanjava.com ，下圖為瀏覽器控制臺信息：

從上圖，我們看到了 302狀態碼并且請求被 Location到另外一個 URL，整個交互流程圖如下：

是不是有一種偷梁換柱的感覺？？？

最后，總結下短鏈跳轉的核心思想：

生成隨機碼，將隨機碼和目標 URL（長鏈）的映射關系存入數據庫；
用域名+隨機碼生成短鏈，并推送給目標用戶；
當用戶點擊短鏈后，請求會先到達短鏈系統，短鏈系統根據隨機碼查找出對應的目標 URL，接著將請求 302重定向到目標 URL（長鏈）；

關于重定向有 301 和 302兩種，如何選擇？

302，代表臨時重定向：每次請求短鏈，請求都會先到達短鏈系統，然后重定向到目標 URL（長鏈），這樣，方便短鏈系統做一些統計點擊數等操作；通常采用 302
301，代表永久重定向：第一次請求拿到目標長鏈接后，下次再次請求短鏈，請求不會到達短鏈系統，而是直接跳轉到瀏覽器緩存的目標 URL（長鏈），短鏈系統只能統計到第一次訪問的數據；一般不采用 301。

四、如何生成短鏈？

從短鏈組成章節可知：短鏈=域名+隨機碼，因此，如何生成短鏈的問題變成了如何生成一個全局唯一的隨機碼，通常會有 3種做法：

1. Base62

Base62 表示法是一種基數為62的數制系統，包含26個英文大寫字母（A-Z），26個英文小寫字母（a-z）和10個數字（0-9）。這樣，共有62個字符可以用來表示數值。如下代碼：

import java.security.SecureRandom;

publicclass RandomCodeGenerator {
privatestaticfinal String CHAR_62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
privatestaticfinal SecureRandom random = new SecureRandom();

public static String generateRandomCode(int length) {
    StringBuilder sb = new StringBuilder(length);
    for (int i = 0; i < length; i++) {
      int rndCharAt = random.nextInt(CHAR_62.length());
      char rndChar = CHAR_62.charAt(rndCharAt);
      sb.append(rndChar);
    }
    return sb.toString();
  }
}

對于 Base62算法，如果是生成 6位隨機數有 62^6 - 1 = 56800235583（568億多），如果是生成 7位隨機數有 62^7 - 1 = 3521614606208（3.5萬億多），足夠使用。

2. Hash算法

Hash算法是我們最容易想到的辦法，比如 MD5, SHA-1, SHA-256, MurmurHash, 但是這種算法生成的 Hash值還是比較長，常用的做法是把這個 Hash值進行 62/64進行壓縮。

如下代碼，通過 Google的 MurmurHash算法把長鏈 Hash成一個 32位的 10進制正數，然后再轉換成62進制（壓縮），這樣就可以得到一個 6位隨機數，

import com.google.common.hash.HashFunction;
import com.google.common.hash.Hashing;
import java.nio.charset.StandardCharsets;

publicclass MurmurHashToBase62 {

    privatestaticfinal String BASE62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
    public static String toBase62(int value) {
        StringBuilder sb = new StringBuilder();
        while (value > 0) {
            sb.insert(0, BASE62.charAt(value % 62));
            value /= 62;
        }
        return sb.toString();
    }
    public static void main(String[] args) {
        // 長鏈
        String input = "https://yuanjava.cnposts/short-link-system/design?code=xsd&page=1";
        // 長鏈利用 MurmurHash算法生成 32位 10進制數
        HashFunction hashFunction = Hashing.murmur3_32();
        int hash = hashFunction.hashString(input, StandardCharsets.UTF_8).asInt();
        if (hash < 0) {
            hash = hash & 0x7fffffff; // Convert to positive by dropping the sign bit
        }
        // 將 32位 10進制數 轉換成 62進制
        String base62Hash = toBase62(hash);
        System.out.println("base62Hash:" + base62Hash);
    }
}

3. 全局唯一 ID

比如，很多大中型公司都會有自己全局唯一 ID 的生成服務器，可以使用這些服務器生成的 ID來保證全局唯一，也可以使用雪花算法生成全局唯一的ID，再經過 62/64進制壓縮。

五、如何解決沖突？

對于上述 3種方法的前 2種：Base62 或者 Hash算法，因為本質上都是哈希函數，所以，不可避免地會產生哈希沖突，盡管沖突的概率已經很低很低了，so，萬一沖突了，該如何解決呢？

要解決沖突，首先需要檢測 Hash沖突，通常來說有 2種檢測方法。

1. 數據庫鎖

這里以 MySQL數據庫為例，表結構如下：

CREATE TABLE`short_url_map` (
`id`int(11) unsignedNOTNULL AUTO_INCREMENT,
`long_url`varchar(160) DEFAULTNULLCOMMENT'長鏈',
`short_url`varchar(10) DEFAULTNULLCOMMENT'短鏈',
`gmt_create`int(11) DEFAULTNULLCOMMENT'創建時間',
  PRIMARY KEY (`id`),
UNIQUEINDEX'short_url' ('short_url')
) ENGINE=InnoDBDEFAULTCHARSET=utf8;

首先創建一張長鏈和短鏈的關系映射表，然后通過給 short_url字段添加唯一鎖，這樣，當數據插入時，如果存在 Hash沖突（short_url值相等），數據庫就會拋錯，插入失敗，因此，可以在業務代碼里捕獲對應的錯誤，這樣就能檢測出沖突。

也可以先用 short_url去查詢，如果能查到數據，說明 short_url存在 Hash沖突了。

對于這種通過查詢數據庫或者依賴于數據庫唯一鎖的機制，因為都涉及DB操作，對數據庫是一個額外的開銷，如果流量比較大的話，需要保證數據庫的性能。

2. 布隆過濾器

在 DB操作的上游增加一個布隆過濾器，在長鏈生成短鏈后，先用短鏈在布隆過濾器中進行查找，如果存在就代表沖突了，如果不存在，說明 DB里不存在此短鏈，可以插入。對于布隆過濾器的選擇，單機可以采用 Google的布隆過濾器，分布式可以使用 RedisBloom。

整體流程可以抽象成下圖：

檢測出了沖突，需要如何解決沖突？

再 Hash，可以在長鏈后面拼接一個 UUID之類的隨機字符串，然后再次進行 Hash，用得出的新值再進行上述檢測，這樣 Hash沖突的概率又大大大降低了。

六、高并發場景的架構

在流量不大的情況，上述方法怎么折騰似乎都合理，但是，為了架構的健壯性，很多時候需要考慮高并發，大流量的場景，因此架構需要支持水平擴展，比如：

采用微服務
功能模塊分離，比如，短鏈生成服務和長鏈查詢服務分離
功能模塊需要支持水平擴容，比如：短鏈生成服務和長鏈查詢服務能支持動態擴容
緩解數據庫壓力，比如，分區，分庫分表，主從，讀寫分離等機制
服務的限流，自保機制
完善的監控和預警機制

這里給出一套比較完整的設計思路圖：

七、總結