1 背景介紹

轉轉是中國領先的二手交易平臺，鏈接作為用戶在平臺上進行交互和信息傳遞的重要媒介，扮演著不可或缺的角色。

圖片

傳統長鏈接通常包含大量字符和特殊符號，不易記憶和傳播。由于字數的原因，長鏈接在發送短信，生成二維碼和社交平臺發布等場合下會也有一定的局限性。

2 工作原理

圖片

2.1 短鏈接生成與存儲

短鏈平臺接收到業務方提供的長鏈接后，先通過哈希算法（MD5）檢查是否已存在短鏈接映射關系，存在即返回，不存在則生成唯一 ID 標識（號段模式），再選擇適當的短鏈接生成算法（Base62），將該唯一 ID 轉換為短鏈接。生成的短鏈接與原始長鏈接之間的映射關系需要被持久化，以便在用戶訪問時能夠快速地查找并定位到原始長鏈接。

2.2 短鏈接返回與傳播

一旦短鏈接生成成功，短鏈平臺將返回這個短鏈接給業務方。業務方可以通過多種方式將短鏈接傳播給用戶，如將其嵌入到網頁中、發送短信、分享到社交媒體等。用戶獲得這個短鏈接后，就可以點擊訪問相應的資源。

2.3 用戶點擊與跳轉

當用戶點擊短鏈接時，瀏覽器向短鏈平臺發送請求。短鏈平臺需要根據短鏈接查找映射關系，然后將用戶正確引導到原始長鏈接的業務系統。這一步驟需要高效的數據檢索和跳轉機制。

HTTP 狀態碼 301 和 302 都能代表重定向，301 永久重定向會使用瀏覽器緩存導致統計短鏈訪問次數不正確，302 臨時重定向會每次都訪問到短鏈平臺從而增加服務壓力。

3 核心算法

長鏈接到短鏈接的轉換是短鏈平臺的核心功能，這需要一個高效且唯一的算法來確保每個長鏈接都可以映射到一個對應的短鏈接。

3.1 哈希算法

3.1.1 MD5

MD5 是一種廣泛應用的哈希算法，將輸入數據轉換為 128 位的哈希值，在短鏈平臺中可以用于生成短鏈接的基礎哈希值。

3.1.2 SHA-256

SHA-256 是一種更安全的哈希算法，它生成256位的哈希值。雖然相對于MD5，SHA-256更安全，但同時也會更長，影響了短鏈接的長度。

3.2 分布式 ID

直接使用哈希結果作為短鏈接時，哈希碰撞和鏈接長度都是需要考慮的問題。在短鏈平臺中，需要采取措施來防止哈希碰撞，例如使用唯一性標識符。

3.2.1 全局遞增

自增 ID 是另一種常見的分布式唯一 ID 生成方式，通過一個自增的計數器來生成唯一 ID。例如 MySQL 的自增主鍵，或者 Redis 的 incr 指令。這種方法簡單且高效，適用于許多場景。

3.2.2 號段模式

號段模式會為不同的節點分配不同的號段范圍，每個節點內部自增生成唯一的 ID，用完后再重新分配，從而確保全局唯一性。

圖片

3.2.3 SnowFlake

SnowFlake（雪花算法）是一種常用的分布式唯一 ID 生成算法，它將一個大整數 ID 拆分成多個部分，包括時間戳、機器 ID、數據中心 ID 和序列號等，從而保證了生成的 ID 是唯一且遞增的。

圖片

然而，盡管雪花算法在分布式環境中生成唯一 ID 方面表現出色，但它并不免疫于時鐘回撥問題。如果發生時鐘回撥，可能會導致生成的 ID 在時間上產生逆序。

3.3 Base62 編碼

Base62 編碼是將數據轉換為只包含數字和字母的一種方法。它使用了 62 個字符，分別是 0-9、a-z、A-Z，可以作為 URL 短鏈接、文件名等場景的字符串表示，相對于16進制或64進制等其他編碼，Base62 具有更高的可讀性和穩定性。

import java.util.ArrayList;
import java.util.List;

public class Base62Encoder {

    private static final String BASE62_CHARACTERS = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

    public static String encode(long num) {
        StringBuilder sb = new StringBuilder();
        do {
            int remainder = (int) (num % 62);
            sb.insert(0, BASE62_CHARACTERS.charAt(remainder));
            num /= 62;
        } while (num != 0);
        return sb.toString();
    }
}

僅 6 位的 Base62 編碼，能表示約 568 億（62 的 6 次方）的數。

4 安全與防護

在轉轉短鏈平臺的設計與實現過程中，確保用戶數據的安全性和平臺的穩定性是首要任務。為此，我們采用了一系列安全與防護策略，以應對潛在的風險和威脅，保障用戶隱私和系統的正常運行。

4.1 長鏈接合法性校驗

在生成短鏈接之前，首先需要對用戶提供的原始長鏈接進行驗證，以確保鏈接指向的是合法且可信任的目標資源。

合法性校驗通常涵蓋以下幾個方面：

1. 主域名合法性： 首先，平臺會解析原始長鏈接，提取其中的域名信息。然后，這個域名會與預先定義的合法域名列表進行比對，以確認鏈接是否指向了預期的域名。這樣做可以有效地防止惡意鏈接或指向不安全網站的情況。
2. 查詢參數域名合法性： 鏈接中的查詢參數域名也可能影響到用戶安全。平臺也需要驗證這些域名是否合法，以免引發潛在的安全風險。

4.2 重復生成短鏈接防護策略

重復生成短鏈接的防護策略在短鏈平臺的設計中具有重要意義。它旨在防止因重復生成相同的短鏈接而造成的資源浪費和系統混亂。

短鏈平臺可以基于長鏈接的 MD5 值采用冪等性設計，確保多次相同請求的處理結果是一致的，不會產生額外的短鏈接。

4.3 短鏈接有效性驗證

在用戶點擊或輸入短鏈接后，短鏈平臺需要快速準確地判斷該鏈接是否有效，從而決定是否將用戶重定向到原始長鏈接或提供相應的錯誤信息。

短鏈平臺會通過查詢數據庫來驗證短鏈接的有效性。如果短鏈接與有效的映射關系存在，平臺將確認鏈接有效，否則將判定鏈接無效。

5 系統性能優化

系統性能的優化是確保轉轉短鏈平臺高效、穩定運行的關鍵。通過采用一系列策略和技術，我們不斷提升平臺的響應速度、并發處理能力和資源利用效率，以滿足用戶的需求并提供卓越的用戶體驗。

5.1 數據庫索引

數據庫是短鏈平臺的核心數據存儲組件，因此優化數據庫的設計和訪問非常重要。將長鏈接的唯一標識 ID 作為主鍵索引，長鏈接的 MD5 值作為普通索引，以支持快速的鏈接有效性驗證和重定向操作。

5.2 緩存應用

利用緩存技術可以顯著減少數據庫訪問次數，從而提高系統的響應速度。我們采用了分布式緩存 Redis，將短鏈接映射關系異步存儲在緩存中，減輕數據庫的壓力。這樣可以在高并發情況下，快速地獲取鏈接映射信息，提升用戶訪問的效率。

5.3 號段模式優化

傳統號段模式在節點消耗完所有號段時才會向發號器請求分配新的號段，這可能會引起短時間內的性能瓶頸。我們引入獨立的監控線程定期檢查號段的使用情況，一旦使用 ID 數量超過閾值時就請求分配新的號段。新的號段模式能夠在高并發情況下平穩地切換號段，通過預先分配號段以避免阻塞業務流程，從而提高系統的性能和穩定性。

圖片

5.4 分表策略

隨著用戶數量和鏈接數據的增長，單一數據庫表可能會面臨性能瓶頸。為了應對這個問題，我們采用了分表策略。將鏈接數據按照唯一性 ID 對 64 取余的規則均勻拆分到 64 張表中，可以有效減輕單一表的壓力，提高數據庫的擴展性和性能。

5.5 業務監控

業務監控是系統關鍵環節之一，旨在實時追蹤系統的性能和運行狀況，以確保高可用性和高性能。借助轉轉監控系統 Prometheus，我們可以收集和展示關鍵的性能指標，如生成短鏈鏈接和獲取長鏈接的請求頻率，鏈接的安全性校驗情況等等，使能夠一目了然地查看系統運行情況，從而更好地進行決策和優化。

圖片

6 總結

通過深入的研究和實踐，轉轉的短鏈平臺為用戶提供了高效、安全的鏈接服務。在不斷發展的互聯網環境下，短鏈平臺將持續創新，滿足用戶不斷變化的需求。

關于作者：

曹建濤，轉轉C2C&寄賣業務研發工程師