系統架構


Posted by chihyu on 2021-01-25

系統架構

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


#Web #scalibility #DNS #Domain #Load Balancer #TinyURL







Related Posts

使用 Javascript 取得元素的座標

使用 Javascript 取得元素的座標

Google python code style

Google python code style

[03] v-slot ( slot, slot-scope )

[03] v-slot ( slot, slot-scope )


Comments