短網址系統(tǒng)設計思路

時間：2023-06-04 23:42:02 | 來源：網站運營

時間：2023-06-04 23:42:02 來源：網站運營

短網址系統(tǒng)設計思路：差不多 5 年前逛 github 的時候偶然發(fā)現(xiàn)了 hashids 這個東西，當時就覺得 hashids 很適合用在短網址系統(tǒng)上，于是花了一天時間擼了個簡單的短網址系統(tǒng)出來。

當時是純粹為了練手，項目寫完放 github 上，然后就在 v2ex 上發(fā)了個貼，最初稍微維護了一下后來也就沒有再管。前幾天上 github 發(fā)現(xiàn)，這個幾年沒維護的項目靠自然流量也有 200 star 了，看來短網址這個東西的需求仍然很旺盛。

現(xiàn)在回過頭來看當時的實現(xiàn)方案還是比較粗糙的，個人項目玩玩可以，用在商業(yè)生產環(huán)境就不太夠了。不過目前倒也沒有自建短網址的需求，不會再像當時一樣自己再擼一套，但短網址系統(tǒng)的設計思路和一些坑倒是可以整理一下。

背景

什么是短網址系統(tǒng)？

短網址已經是一個老生常談的話題了，這塊想必不用多說，它的作用主要就是把一個很長的網址轉換成一個較短的地址。像微博的 http://t.cn、百度的 http://dwz.cn、騰訊的 http://url.cn 都是常見的短網址系統(tǒng)。

為什么要用短網址系統(tǒng)？

現(xiàn)在的很多鏈接由于需要帶上很多參數(shù)來提供業(yè)務所需的數(shù)據(jù)，所以往往非常冗長，而相應地轉換成短網址后能帶來很多益處：

• 在分發(fā)和使用的時候更方便、清爽
• 更好地適應微博、短信等有字數(shù)限制的場景
• 降低生成二維碼的復雜度，提升掃碼識別率
• 可以一定程度上隱藏部分參數(shù)，比如 aff 等
• 能夠實現(xiàn)鏈接跳轉的跟蹤和各維度數(shù)據(jù)統(tǒng)計
• 原網址失效后可以不改變短網址，只修改跳轉關系
• 個性短網址更有利于品牌建設和營銷

設計思路

短網址系統(tǒng)做到可用是比較簡單的，但是想要高性能、可靠且安全的話，涉及到的很多點也能展開得非常細。

長短鏈映射

短網址系統(tǒng)最核心的功能就是長短鏈之間的轉換了，長網址的長度可以認為是沒有限制的，所以使用可逆的壓縮或者加密算法將其轉換成一個長度有限的短網址是不可能做到的，我們必須借助 DB 或者其他存儲系統(tǒng)來實現(xiàn)映射的存儲。

發(fā)號

那么自然會產生的一種思路就是將長網址存入一張表，然后使用 DB 中的自增主鍵來作為短網址，此時我們得到的短網址類似這樣 xx.xx/1、xx.xx/2。這其實就是發(fā)號式短網址的基本思路。

在此基礎上我們可以做一些微小的改良來得到更短的鏈接，比如把 10 進制的 ID 轉換成 16 進制，或者 a-z A-Z 0-9 這些字符組成的 62 進制，此時在數(shù)字比較大的時候我們得到的短網址就會類似 xx.xx/Ad3Ef。

上面一步完成后得到的地址看上去就和目前常見的短網址非常相似了，但這種直接暴露 ID 的方式會產生安全上的問題，別有用心的人發(fā)現(xiàn)短網址的規(guī)律之后可以很輕易地遍歷出整個系統(tǒng)中存儲的所有長網址了。這就意味著可能會被人直接拖庫。

文中最初提到的 hashids 則是解決這個問題的一個極佳方案。它提供一種能把任意正整數(shù)轉換為指定位數(shù)字符串的可逆算法，基于 salt 安全性也有保障。并且雖然它名字中含有 hash，但實際生成的字符串不會發(fā)生碰撞，當數(shù)字過大無法用指定位數(shù)字符串表示的時候會自動增加一位。

實測下來使用 62 進制字符串的情況下，6 位長度字符串可以表示至少 1 億條數(shù)據(jù)，7 位長度可以表示近 50 億條數(shù)據(jù)，可以說完全足夠業(yè)務使用了。至于 hashids 的具體實現(xiàn)原理可以查看它的官網介紹。

Hash

既然使用發(fā)號的方式也不能直接暴露 ID，那是否也可以使用 hash 來進行長網址的縮短呢？我們都知道 hash 是一定會存在碰撞的，在長地址空間不確定的情況下，碰撞概率以及碰撞后的處理都會存在很大的不確定性，所以一般來說 hash 在大規(guī)模的線上短鏈接系統(tǒng)中是不能被接受的。

不過近些年才出現(xiàn)的 MurmurHash對于類似場景則有一定程度的優(yōu)化，它誕生也就十年出頭，就已經被很多著名的開源項目使用，比如 Redis、Nginx、Hadoop 等等。對于規(guī)律性較強的 key，它的隨機分布特征表現(xiàn)更良好，更好的平衡性和更低的碰撞率使得它也能夠在特定場景下用于短網址系統(tǒng)。

重定向跳轉

實現(xiàn)了長短鏈的映射轉換之后，只要再完成短鏈到長鏈的重定向跳轉也就實現(xiàn)了短網址系統(tǒng)的核心功能了。

重定向這塊主要涉及的是 301 和 302 的選擇，當然 http 的跳轉除了 301、302 之外 還有 303、307、308，不過在短網址系統(tǒng)中一般是用不到的。

簡單來說 301 是永久重定向，302 是臨時重定向。如果短鏈生成后就不會變化，那么使用 301 則更符合 http 語義，同時瀏覽器會緩存 301 跳轉，這也能很大程度上減輕服務器壓力。

不過在很多使用場景中我們往往都想要對鏈接跳轉的數(shù)據(jù)進行統(tǒng)計，而且如果我們也需要實現(xiàn)活鏈功能，也就是同一個短鏈指向的長鏈后續(xù)可以修改的話，那就只有選擇 302。

優(yōu)化

上面兩步做完之后，一個簡單的可用的短網址系統(tǒng)就實現(xiàn)了，不過如果想要在大型商用系統(tǒng)中使用還是需要做些性能上的優(yōu)化。

緩存

性能優(yōu)化最基本的自然是緩存，短鏈到長鏈的轉換基本上就是一個 key-value 的查詢過程，所以使用常見的 Redis 等緩存方案來緩存長短鏈的對應關系再合適不過了。先走緩存再查數(shù)據(jù)庫，數(shù)據(jù)庫對應字段索引合理的情況下，整個系統(tǒng)的性能就不會差。

在緩存大小有限的情況下也可以選擇緩存熱點數(shù)據(jù)，至于涉及到的其他諸如分布式緩存、緩存穿透和雪崩、遷移數(shù)據(jù)預熱等等展開來又是一個比較大的話題了。

布隆過濾器

布隆過濾器也是一種非常適用于短網址系統(tǒng)的算法，它可以用來快速判斷某個 url 是否在大量的 url 集合當中，并且空間復雜度也很低，我們大約只要 500M 左右的內存空間就能完成 20 億左右 url 集合的判斷。

布隆過濾器的具體原理就不贅述了，大概講講它在前面提到的發(fā)號和 Hash 兩種長短鏈映射方式中的使用場景。

在發(fā)號式生成短鏈的系統(tǒng)中，如果同一個長鏈被轉換多次，那么在沒有判斷長鏈是否已存在的情況下，這個地址會被轉換成多個不同的短鏈。如果我們希望同一個長鏈多次轉換的結果相同，那么查庫顯然比較低效，而緩存是 key-value 的，反過來查詢 value 也很低效，這時就可以使用布隆過濾器。

而在 Hash 生成短鏈的系統(tǒng)中，布隆過濾器則可以用來很方便地判斷哈希碰撞，所以說這個算法非常適合各種短網址系統(tǒng)。

發(fā)號器選擇

發(fā)號式生成短網址方式的核心是發(fā)號器，也就是 ID 生成器，一般來說使用 MySQL 等數(shù)據(jù)庫的自增主鍵就夠了，畢竟大多數(shù)短網址系統(tǒng)應該是讀操作更多，寫操作較少。

不過硬要深究的話，也可以使用 Redis、Snowflake 來實現(xiàn)發(fā)號器，但這些方案無疑會極大地增加系統(tǒng)復雜度，除非是超大型規(guī)模的短網址項目才會考慮到。或者采用 uuid 的方式實現(xiàn)分布式的 ID 生成，但 uuid 的長度又有些過長了。

語言選擇

語言選擇放在最后是因為個人覺得對于短網址這種簡單業(yè)務來講，在大多數(shù)項目里語言的選擇并不會是一個很關鍵的注意點。

我?guī)啄昵暗哪莻€項目是使用 PHP 加上一個基本只有路由功能的輕框架實現(xiàn)的，在這種文件 IO 較低的場景下主要的開銷其實還是數(shù)據(jù)庫層面的，與加上緩存帶來的提升相比，語言的選擇帶來的影響就比較小了。

當然追求極致性能的話自然是有比 PHP 更適合的選擇的，之前就有人把我的項目用 nginx + lua，也就是 OpenResty 改寫出來一個版本。而現(xiàn)在如果讓我再寫一個短網址系統(tǒng)的話，綜合性能以及開發(fā)和維護成本，我則可能更傾向于使用 Go 來實現(xiàn)。

可能的坑

短網址系統(tǒng)遇到的坑除了技術層面以外，一般都是惡意攻擊和不合規(guī)濫用帶來的。

短網址系統(tǒng)如果在轉換地址的時候沒有限制的話，攻擊者很容易實現(xiàn)無限短址套娃，從而消耗大量服務器資源并產生大量垃圾數(shù)據(jù)，所以一般短網址系統(tǒng)是不讓轉換自身域名的地址的，也不讓轉換其他短網址域名的地址，防止攻擊者通過多個短網址服務實現(xiàn)循環(huán)套娃。

至于不合規(guī)的濫用就主要是，很多涉及賭博色情等行業(yè)的網站會使用公開的短網址系統(tǒng)對他們網址進行包裝，因為他們自己的域名一般已經被很多平臺加入黑名單了，所以通過短網址的方式繞過。一旦遇到這種被濫用的情況，我們的域名很可能就會被微信、QQ、微博等平臺封禁，損失慘重。

也正是因為容易遇到各種惡意使用者，短網址系統(tǒng)目前也很少有開放 API 的，基本都是各大平臺自建之后自己使用，而那些不知名的短網址往往也都死得很快。

參考

• 布隆過濾器：如何快速判斷某URL是否在20億的網址集合中？ - 本站
• Hashids - generate short unique ids from integers
• 短 URL 系統(tǒng)是怎么設計的？ - 本站
• Murmurhash介紹與實現(xiàn)數(shù)據(jù)庫ThinkMo的專欄-CSDN博客
• 短網址系統(tǒng)（一）原理分析 - 簡書
• HTTP 中的 301、302、303、307、308 響應狀態(tài)碼 - 本站