系統架構

系統架構

單點故障 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 的關係?