解密短網址
您是否好奇過，當您點擊一個像 Bitly 或 TinyURL 這樣的短網址時，背後到底發生了什麼事？這不只是一個簡單的連結轉換，而是一場涉及龐大數據、精妙演算法與分散式系統工程的技術盛宴。讓我們一起逆向工程，揭開URL 縮短服務的神秘面紗。
挑戰的規模：不只是縮短而已
要建立一個像 Bitly 一樣的服務，我們首先要面對的是驚人的流量與數據量，這決定了整個系統架構的複雜度。
每日新增網址
相當於每秒要處理超過 1,000 個新的短網址生成請求。
每秒點擊次數
點擊（讀取）的頻率遠高於創建（寫入），讀取效能至關重要。
十年總儲存量
需要儲存 3650 億筆對應關係，光是網址本身就需約 36 TB 的空間。
如何產生短網址？
核心問題是：如何在確保唯一性的前提下，有效地產生夠短的網址？這背後有數學和演算法的巧思。
需要多短才夠？
我們的短網址可以使用 0-9、a-z、A-Z，共 62 個不同的字元。為了應對未來十年的 3650 億個網址需求，我們需要計算出最短的字元長度。
可產生的唯一組合數量：
計算結果顯示，7 個字元的長度可以產生約 3.5 兆種組合，遠超過我們的需求，因此是個理想的選擇。
兩種方法的比較
| 特性 | 方法一：雜湊 (Hashing) | 方法二：計數 + Base62 |
|---|---|---|
| 基本原理 | 將長網址通過 MD5 等雜湊函式運算，取前 7 個字元。 | 為每個長網址分配一個唯一的遞增數字 ID，再將 ID 轉換為 Base62 字串。 |
| 優點 | 無狀態，同樣的長網址會得到同樣的結果。 | 保證不重複（無碰撞）、效率高、演算法簡單。 |
| 缺點 | 可能發生「碰撞」，需要多次查詢資料庫確認唯一性，效能較差。 | 需要一個能跨伺服器生成唯一 ID 的系統；短網址有順序性，可能被猜到。 |
| 結論 | 實作簡單，但規模化後效能瓶頸明顯。 | 更優雅、高效的方案，是大型系統的首選。 |
體驗 Base62 轉換
Base62 轉換是方法二的核心。原理是不斷地將數字除以 62，並收集餘數，最後將餘數序列轉換為對應的字元。讓我們以影片中的例子 URL 編號 11157 來試算看看。
點擊後的旅程
產生短網址只是故事的一半。當使用者點擊短網址時，系統需要在毫秒內完成查找和重定向，這對讀取效能是極大的考驗。
從點擊到跳轉的流程
tinyurl.com/2tx
優先在記憶體中尋找，速度最快。
若快取未命中，則查詢資料庫。
伺服器回傳原始長網址，瀏覽器跳轉。
這個過程中，快取扮演了關鍵角色。由於熱門連結會被反覆點擊，將其對應關係存放在快取中可以大幅減少對後端資料庫的壓力。同時，HTTP 301 狀態碼會告訴瀏覽器這個網址已經「永久」移到新位置，瀏覽器可能會記住這個結果，下次直接跳轉，進一步提升效率。
真實世界的工程挑戰
一個看似簡單的服務，在真實世界中會演變成一個複雜的分散式系統。除了前面提到的功能，還需要考慮更多工程問題。
資料庫擴展
單一資料庫無法應付每秒上萬次的查詢。需要使用「資料庫分片 (Sharding)」，將數據分散到多台伺服器上，並設計合理的路由策略。
速率限制
為了防止惡意使用者濫用服務（例如大量生成短網址），需要對 IP 或使用者進行速率限制。
數據分析
追蹤每個短網址的點擊次數、來源、時間等數據，為使用者提供有價值的分析報告，這是服務變現的重要一環。
安全性
必須建立機制來封鎖惡意或釣魚網站的網址，保護使用者不被導向危險的網站，這需要維護一個黑名單資料庫。
不只是短網址：無所不在的設計模式
從「把網址變短」這個簡單需求出發，我們探討的技術其實是現代大型網路應用程式的基石。這些設計模式在各大科技公司中隨處可見。
唯一 ID 生成
類似 Base62 的唯一 ID 生成策略，被用於：
- Instagram: 為每張照片和影片生成唯一 ID。
- Twitter: 為每則推文生成唯一 ID (Snowflake 演算法)。
快取策略
高效的快取機制，被用於：
- Netflix: 快取影片的中繼資料（如封面、演員），加速頁面載入。
- Facebook: 快取使用者個人檔案和動態消息。
資料庫分片
將龐大數據分散儲存的技術，被用於：
- Uber: 按地理區域或時間分割行程資料。
- Slack: 將不同團隊的訊息資料分散到不同資料庫。
下次當您點擊一個短網址時，您會知道，背後有一個龐大而精密的系統，在毫秒之間為您完成任務。而這些核心技術，正驅動著您每天使用的每一個應用程式。