面試官說：你來設計一個短連結生成系統吧

秦怀杂货店發表於2021-12-04
面試

引言

相信大家在生活中，特別是最近的雙十一活動期間，會收到很多簡訊，而那些簡訊都有兩個特徵，第一個是幾乎都是垃圾簡訊，這個特點此處可以忽略不計，第二個特點是連結很短，比如下面這個：

20211110222405

我們知道，簡訊有些是有字數限制的，直接放一個帶滿各種引數的連結，不合適，另外一點是，不想暴露引數。好處無非以下：

  • 太長的連結容易被限制長度
  • 短連結看著簡潔，長連結看著容易懵
  • 安全，不想暴露引數
  • 可以統一連結轉換，當然也可以實現統計點選次數等操作

那背後的原理是什麼呢？怎麼實現的？讓你實現這樣的系統，你會怎麼設計呢？【來自於某鵝場面試官】

短連結的原理

短連結展示的邏輯

這裡最重要的知識點是重定向，先複習一下http的狀態碼：

分類含義
1**伺服器收到請求，需要請求者繼續執行操作
2**成功，操作被成功接收並處理
3**重定向，需要進一步的操作以完成請求
4**客戶端錯誤，請求包含語法錯誤或無法完成請求
5**伺服器錯誤，伺服器在處理請求的過程中發生了錯誤

那麼以 3 開頭的狀態碼都是關於重定向的：

  • 300：多種選擇，可以在多個位置存在
  • 301：永久重定向，瀏覽器會快取，自動重定向到新的地址
  • 302：臨時重定向，客戶端還是會繼續使用舊的URL
  • 303：檢視其他的地址，類似於301
  • 304：未修改。所請求的資源未修改，伺服器返回此狀態碼時，不會返回任何資源。
  • 305：需要使用代理才能訪問到資源
  • 306：廢棄的狀態碼
  • 307：臨時重定向，使用Get請求重定向

整個跳轉的流程：

  • 1.使用者訪問短連結，請求到達伺服器

  • 2.伺服器將短連結裝換成為長連結，然後給瀏覽器返回重定向的狀態碼301/302

    • 301永久重定向會導致瀏覽器快取重定向地址，短連結系統統計訪問次數會不正確
    • 302臨時重定向可以解決次數不準的問題，但是每次都會到短連結系統轉換，伺服器壓力會變大。
  • 3.瀏覽器拿到重定向的狀態碼，以及真正需要訪問的地址，重定向到真正的長連結上。

從下圖可以看出，確實連結被302重定向到新的地址上去，返回的頭裡面有一個欄位Location就是所要重定向的地址：

<img src="https://markdownpicture.oss-cn-qingdao.aliyuncs.com/blog/20211110235518.png" style="zoom:70%;" />

短連結怎麼設計的？

全域性發號器

肯定我們第一點想到的是壓縮，像檔案壓縮那樣，壓縮之後再解壓還原到原來的連結，重定向到原來的連結，但是很不幸的是，這個是行不通的，你有見過什麼壓縮方式能把這麼長的數字直接壓縮到這麼短麼？事實上不可能。就像是Huffman樹，也只能對那種重複字元較多的字串壓縮時效率較高，像連結這種，可能帶很多引數，而且各種不規則的情況都有，直接壓縮演算法不現實。

那https://dx.10086.cn/tzHLFw與https://gd.10086.cn/gmccapp/webpage/payPhonemoney/index.html?channel=之間的裝換是怎麼樣的呢？前面路徑不變，變化的是後面，也就是tzHLFw與gmccapp/webpage/payPhonemoney/index.html?channel=之間的轉換。

實際也很簡單，就是資料庫裡面的一條資料，一個id對應長連結（相當於全域性的發號器，全域性唯一的ID）：

idurl
1https://gd.10086.cn/gmccapp/w...

這裡用到的，也就是我們之前說過的分散式全域性唯一ID，如果我們直接用id作為引數，貌似也可以：https://dx.10086.cn/1，訪問這個連結時，去資料庫查詢獲得真正的url，再重定向。

單機的唯一ID很簡單，用原子類AtomicLong就可以，但是分散式的就不行了，簡單點可以用 redis，或者資料庫自增，或者可以考慮Zookeeper之類的。

id 轉換策略

但是直接用遞增的數字，有兩個壞處：

  • 數字很大的時候，還是很長
  • 遞增的數字，不安全，規律性太強了

明顯我們平時看到的連結也不是數字的，一般都是大小寫字母加上數字。為了縮短連結的長度，我們必須把id轉換掉，比如我們的短連結由a-z,A-Z,0-9組成，相當於62進位制的數字，將id轉換成為62進位制的數字:

public class ShortUrl {

    private static final String BASE = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

    public static String toBase62(long num) {
        StringBuilder result = new StringBuilder();
        do {
            int i = (int) (num % 62);
            result.append(BASE.charAt(i));
            num /= 62;
        } while (num > 0);

        return result.reverse().toString();
    }

    public static long toBase10(String str) {
        long result = 0;
        for (int i = 0; i < str.length(); i++) {
            result = result * 62 + BASE.indexOf(str.charAt(i));
        }
        return result;
    }

    public static void main(String[] args) {
        // tzHLFw
        System.out.println(toBase10("tzHLFw"));
        System.out.println(toBase62(27095455234L));
    }
}

id轉 62位的key 或者key裝換成為id都已經實現了，不過計算還是比較耗時的，不如加個欄位存起來，於是資料庫變成了：

idkeyurl
27095455234tzHLFwhttps://gd.10086.cn/gmccapp/w...

但是這樣還是很容易被猜出這個id和key的對應關係，要是被遍歷訪問，那還是很不安全的，如果擔心，可以隨機將短連結的字元順序打亂，或者在適當的位置加上一些隨機生成的字元，比如第1，4，5 位是隨機字元，其他位置不變，只要我們計算的時候，將它對應的關係存到資料庫，我們就可以透過連線的key找到對應的url。（值得注意的是，key必須是全域性唯一的，如果衝突，必須重新生成）

一般短連結都有過期時間，那麼我們也必須在資料庫裡面加上對應的欄位，訪問的時候，先判斷是否過期，過期則不給予重定向。

效能考慮

如果有很多短連結暴露出去了，資料庫裡面資料很多，這個時候可以考慮使用快取最佳化，生成的時候順便把快取寫入，然後讀取的時候，走快取即可，因為一般短連結和長連結的關係不會修改，即使修改，也是很低頻的事情。

如果系統的id用完了怎麼辦？這種機率很小，如果真的發生，可以重用舊的已經失效的id號。

如果被人瘋狂請求一些不存在的短連結怎麼辦？其實這就是快取穿透，快取穿透是指，快取和資料庫都沒有的資料，被大量請求，比如訂單號不可能為-1，但是使用者請求了大量訂單號為-1的資料，由於資料不存在，快取就也不會存在該資料，所有的請求都會直接穿透到資料庫。如果被惡意使用者利用，瘋狂請求不存在的資料，就會導致資料庫壓力過大，甚至垮掉。

針對這種情況，一般可以用布隆過濾器過濾掉不存在的資料請求，但是我們這裡id本來就是遞增且有序的，其實我們範圍大致都是已知的，更加容易判斷，超出的肯定不存在，或者請求到的時候，快取裡面放一個空物件也是沒有問題的。

【作者簡介】：
秦懷，公眾號【秦懷雜貨店】作者，技術之路不在一時，山高水長，縱使緩慢，馳而不息。個人寫作方向：Java原始碼解析，JDBC，Mybatis，Spring，redis，分散式，劍指Offer，LeetCode等，認真寫好每一篇文章，不喜歡標題黨，不喜歡花裡胡哨，大多寫系列文章，不能保證我寫的都完全正確，但是我保證所寫的均經過實踐或者查詢資料。遺漏或者錯誤之處，還望指正。

劍指Offer全部題解PDF

2020年我寫了什麼？

開源程式設計筆記

相關文章