系統架構
單點故障 Single Point of Failure：一個地方掛了，整個都掛了
備份機制：為了避免這樣的事發生，會有備份資料庫，如果一個資料庫掛了，還有另外一個可以用
虛擬主機(Web hosting)
虛擬主機是由實體主機分割出的一個個虛擬空間，一個虛擬空間就是虛擬主機，功能與實體主機一樣
網域(Domain)
可以進入網站路口的位置，將虛擬主機比喻為房子，網域名稱(網址)就是虛擬主機的地址，透過網址找到虛擬主機，請求該網址內容
網域設定：利用 A 設定，連結網域名稱與 IP 位置
DNS(Domain name system)
網址與 IP 之間的橋樑
- A：網址與 IP 的雙向對應綁定，綁定 IPv4
- AAAA：綁定 IPv6
- C Name：讓更多的網址名稱可以查詢
Saclability
對系統添加資源以應對增加的工作量
添加方式：
- 橫向擴展(Horizontal Scaling) - 增加機器數量，可以無限擴展，沒有頂配的問題，多個組件取代單一組件，透過冗餘提高可靠性
- 縱向擴展(Vertical Scalint) - 提升單個機器的配置，但會達到頂配時就不能再進升級了
負載均衡器 Load Balancer
把用戶請求分發到多個伺服器上，利用多台伺服器提供單一服務，處理資源分配的問題
分發方法：
- 輪循(輪流) Round robin
- 隨機
- 依據情況 (基於負載情況分發最理想)
有關聯的請求(ex. 登入、下單)可能分發到不同伺服器，解決方法：
- 把有關連的請求都發到同一個伺服器
- 把 session 存放在讓所有伺服器都可以存取的地方
冗餘負載均衡器
負載均衡器也需透過冗餘來避免單點故障(Single Point of Failure)
故障轉移模式：
- 主動-被動(active-passive)：主動的運作，被動的備用，主動壞了，才會還成被動的
- 被動-被動(passive-active)：兩個同時運作，一個壞掉了不會影響
快取 (緩存) cache
對處理過的資料作快取，用來加速 GET
短網址
把一般的網址轉成比較短的網址
點擊短網址，重新導向到原始 URL
原理：輸入短網址時，DNS 先解析 IP 位置，獲取 IP 位置後發送 HTTP GET 請求，查詢短網址，伺服器再透過短網址取得對應的長網址，再用 HTTP 301 發請求到長網址
設計需求：
功能面向
- 給定原始 URL，產生一個短且唯一的短網址
- 訪問短網址時，重新導向到原始 URL
- 可自定義短網址
- 允許設置時效性
系統面向
- 需具可靠性，避免當機時 URL 重新導向失敗
- 盡量減少重新導向的延遲性
- 不可預測(?)
- 其他
- 可以分析(ex. 計算重新導向了幾次)
- 提供 API 服務
數據庫設計：
- 儲存原始 URL 對應的資料
- 儲存短網址用戶資料
Zookeeper
- 管理增加的數 main increasing counter
- 輕易新增或移除 application server
- original_url + incrementing_counter 下去Hash
- 避免碰種問題(collision)
- 減少 DB CALL
Key Generating Service
- offline 生成短碼
- 從 Key DB 預先取得短碼儲存
算法：
- 自增序列算法(不重複算法)
低進位轉成高進位，字符會減少，短網址有 6 個字，每個字都是 62 進位 - 摘要算法
參考資料：
Scalability_系统设计笔记1
負載均衡
經典系統設計面試題解析：如何設計TinyURL（一）
系統設計 - 設計縮網址服務
Q：Zookeeper 跟 Load Balancer 的關係?
