數據庫設計思路和要點

基本概念

• 單庫 
  

• 分片 
  

  解決單個數據表數據量太大的問題，將單個表的數據均勻的放入多個表中

• 複製 
  

  用於實現主從同步，主庫的更新操做（insert/update/delete）向從庫（1個或多個）進行同步，同步成功完成後主庫和從庫的數據是一致的，可是在同步過程的時間窗口內，主從數據是不一致的。

• 分片 + 分組 
  

• 路由

  根據userid或PK將SQL請求路由至正確的分片實例中，常見的路由策略有：

  1. 號段 
     算法：好比[1, 1kw]爲一個分片，[1kw,2kw]爲一個分片。 
     優勢：實現簡單，數據分佈均勻 
     缺點：請求可能不均勻，好比有些業務場景下新增的用戶請求量更大。
  2. Hash 
     算法：Hash(userid) % 分片個數 
     優勢：實現簡單，數據分佈均勻，請求分佈均勻 
     缺點：新增分片須要遷移數據，可採用一致性Hash減小須要遷移的數據量

可用性

讀高可用

解決辦法：： 

互聯網應用的特色是絕大部分請求都是讀請求，經過一主多從、冗餘從庫、讀寫分離的方式，經過增長從庫數量，能夠有效的提高讀請求的性能和可靠性。主庫只處理寫請求，從庫處理讀請求。

存在問題：

1. 寫庫是單點，沒法保障高可用
2. 主從同步須要時間，在這段同步的時間窗口內，讀請求可能會讀到舊數據

寫高可用

解決辦法一：雙主 

經過冗餘寫庫的方式實現寫庫的高可用，寫庫之間進行數據複製： 
缺點： 
1. 多個寫庫之間的同步容易出現衝突，從而致使同步失敗或數據不一致，通常比較少採用這種方式。

解決辦法二：主主同步 + Virtual IP 

經過VIP的方式，正常狀況下讀寫都在其中一個主庫上，同時主庫向另外一臺備用主庫同步數據，當這臺主庫宕機後，VIP浮動到備用主庫，備用主庫處理後續的讀寫請求。 
優勢： 
1. 對應用層透明，應用層只需經過VIP訪問數據庫便可 
2. 故障自動切換，當檢測到主庫故障時，VIP會自動浮動到備用主庫上 
缺點： 
1. 資源利用率只有50% 
2. 讀寫流量都落在主庫上，沒有經過從庫的方式提升讀性能

讀高性能

解決辦法一：冗餘從庫、讀寫分離 

解決辦法二：緩存 

引入Cache後應用層的讀寫流程變爲： 
讀流程： 
1. 讀Cache 
2. 成功讀到數據後直接返回，Cache Miss則讀DB 
3. 用從DB讀到的數據去更新Cache 
寫流程： 
1. 淘汰Cache 
2. 更新DB

注意，這裏在極端狀況下，會出現讀寫一致性問題：寫請求淘汰了Cache，可是還未更新DB成功，這時另外一個讀請求到來，讀請求讀Cache時Miss，從而去DB加載數據，而此時的數據仍是舊數據，由於寫流程中更新DB那一步驟還未完成，因此此時讀請求讀到的是舊數據，而且將舊數據也放入了Cache中，致使後續全部的讀請求都讀到舊數據，直到下一次寫請求到來。

解決這個問題的辦法有兩種： 
1. 爲每一個緩存項設置過時時間，過時時間到達以後該緩存項會失效，從而致使讀請求穿透到DB，從而強制去DB加載一次最新數據。 
2. 在寫流程中增異步淘汰緩存的流程（雙淘汰）：

寫流程變爲： 
1. 淘汰Cache 
2. 更新DB 
3. 異步淘汰Cache，好比：利用定時器或定時隊列，在60s後主動淘汰Cache，致使讀請求穿透到DB去強制加載一次最新數據

讀寫一致性

使用一主多從架構時，因爲主從同步須要一段時間開銷，所以在這段時間窗口內數據會不一致性，表現出來的現象就是應用層讀不到剛纔寫入的數據。

解決辦法：強制讀主 
引入一個數據訪問中間件，將主從同步時間窗口內的請求路由到主庫