談談數據庫的高可用架構
前言
本篇文章討論一下數據庫高可用的相關架構。
1. 數據庫的高可用
數據庫的高可用從下面幾點考慮
- 高可用
- 高性能
- 可拓展
- 一致性
1.1 水平切分
主要解決單數據庫中數據量過多的問題。水平划分成多個庫負載均衡。
1.1.1 如何划分數據
- 通過范圍
- 時間或者主鍵id划分，缺點是各個庫的壓力不均
- 通過哈希 建議
- 存儲查詢時取模計算在那個庫，缺點是當兩個庫拓展成三個庫時麻煩，（數據需要遷移）
- 通過統一路由服務
- 業務與路由算法解耦
1.2 一主多從 讀寫分離
單個主數據庫搭配多個從數據庫來進行使用。主庫負責寫入，從庫負責讀取。同步主庫和從庫的數據。當水平切分遇到主從復制時，划分成的1庫和2庫分別進行讀寫分離。
1.2.1 遇到的問題
數據同步不一致 有一定時間差 (還未同步數據就去讀取)
通常使用中間件或者強制讀主的方式來解決中從數據不一致性問題
- 中間件
- 當某個key有寫操作時，在不一致的時間窗口范圍中關於這個key的讀也路由到主庫中去讀。不再通過從庫去讀。
- 強制讀主
- 也就是雙主高可用的架構
單個主庫也會成為單點，MHA可以在主庫產生故障時進行切換，選舉一個讀庫作為主庫。一主在寫多的場景下也會產生瓶頸，因而拓展主庫也是某些場景需要的。
1.3 多主多從
單個寫庫還是不能保證寫高可用，需要冗余寫庫。
1.3.1 多個寫庫寫到那個庫中？
- 通過多個寫庫不同的初始值，相同步長進行遞增。
- 1寫庫的id為 0 2 4 8 ... 2寫庫的id為 1 3 5 7
- 通過業務層來生成唯一的id 保證數據不沖突
同時帶來的問題也是數據需要同步的地方增多，數據延遲嚴重。
1.4 主備進行高可用
主備架構，只有主庫提供讀寫服務，備庫冗余作故障轉移用
通過虛ip漂移，對業務層透明，不需要人工介入
優點是讀寫沒有延時(寫完就可以讀)，沒有數據一致性問題。
不足的是不能通過加從庫拓展讀性能。資源利用率為50%，一台冗余主沒有提供服務。但如果進行雙主同時提供服務(負載均衡)可以解決這一點，但加了會有數據一致性問題如1.5中所說。
1.4.1 通過 Keepalived + MySQL 實現雙主熱備高可用方案
Keepalived 也就是通過虛擬ip，實現雙主對外的統一接口，自動檢查，失敗切換機制，自動切換防止單點故障。
Keepalived基礎是通過VRRP協議
- VRRP (Virtual Router Redundancy Protocol) 虛擬路由冗余協議。在VRRP中有兩組重要的概念：VRRP路由器和虛擬路由器，主控路由器和備份路由器。
- VRRP路由器是指運行VRRP的路由器，是物理實體，虛擬路由器是指VRRP協議創建的，是邏輯概念。一組VRRP路由器協同工作，共同構成一台虛擬路由器。Vrrp中存在着一種選舉機制，用以選出提供服務的路由即主控路由，其他的則成了備份路由。當主控路由失效后，備份路由中會重新選舉出一個主控路由，來繼續工作，來保障不間斷服務。
1.5 雙主架構 負載均衡
兩個主庫同時提供服務，負載均衡。
讀寫性能相對主備架構得到提升，資源利用率更高。
存在數據一致性問題，也可以水平拓展。但水平拓展會多一層數據同步，同步時間變長。
帶來的問題是數據一致性問題以及主鍵沖突問題(可以通過分布式id解決)
1.6 從庫中如何優化
- 為從庫加入索引 索引可以不同。主庫可以不使用索引，從庫使用不同的索引（從庫使用場景各不相同）。
- 增加從庫
- 從庫越多 同步也慢，同步慢 數據不一致窗口越大。
- 增加緩存
- 也會帶來數據不一致性問題