短網址系統設計看似簡單，裡頭包含眾多細節，關於資料儲存、算法、效能提升等等問題，先從介紹短網址設計目的開始談起，逐步講解圖中的架構。
短網址：把普通的網址轉換成比較短的網址
- 字符變少，在字數限制的平台發文可編輯的字變多
- 容易發布傳送，太長的網址容易截斷或不能被辨識為連結
比如今天在瀏覽器輸入這一串短網址：https://reurl.cc/9X0gnv
- 向
https://reurl.cc的 IP 位置發送 GET 請求，查詢9X0gnv這串短碼 https://reurl.ccServer 去資料庫查到它對應的 URL，會通過 HTTP 302 轉址，重定向到使用者真正要訪問的伺服器
302 代表臨時重定向。
每次請求都會去到短網址伺服器，而不像 301 是第一次拿到之後存起來，以後就會從瀏覽器存緩裡面拿、搜尋直接顯示真實地址，不經過短網址伺服器，這也意味著我們無法統計到它被點擊的次數、無法蒐集到使用者 Cookie、User Agent 等資料，就沒辦法做大數據分析（這是短網址服務主要獲利來源），所以一般是採用 302 重定向。
簡單來說，就是將長網址和通過算法得到的短碼在資料庫中關聯起來，這裡介紹兩種算法：
- 自增序列算法
利用 id 自增，一個十進制的 id 對應一個 62 進制的數值，不會出現重複的情況，利用 進制轉換 的方式取得短碼，再把它拼接到域名後面形成短網址。
最簡單的方式就是利用 MySQL 默認的主鍵自增來作為 id，優點是擴展方便，不會有衝突。
- MurmurHash
觀察短網址，發現它是由固定域名 + 長網址對應的一串字母/數字組成，這裡重點是如何才取得和長網址對應的字串呢？結合之前存資料庫密碼的經驗，可以使用雜湊，因為它將產生一段幾乎不重複的字串，但是將 MD5 或 SHA 等算法運用到短網址顯得有些小題大作了，畢竟我們的目的只是要產生一段短碼而已，加密並非必要。
所以這裡，其實可以用 MurmurHash，一種非加密型哈希算法，它不是專門設計為不可逆轉破解，而是追求高性能與低碰撞率，優點是算法速度很快，非加密也意味著性能好，符合題目給出的要求，而這個雜湊值是十進位的，同樣可以利用上面的進制轉換來縮短它的長度。
在參考資料中，有提到先檢查資料庫是否已經有該網址對應的短碼，這是關於一對一或是一對多的選擇，我的設計步驟沒有這部分，考量到一個長網址在不同時空背景、不同使用者的狀況下，應該要生成不一樣的短網址。
同樣是基於數據的理由，如果資料庫僅僅只有一行，沒辦法進行分析。
