存儲高可用，一般採用複製架構，複製架構，需要關注故障架構和狀態決策2個要點
複製架構通用關注點
數據複製
複製格式
| 格式 | 優點 | 缺點 | 舉例 |
|---|---|---|---|
| 命令 | 數據量小 | 可能存在數據不一致 | Mysql 的statement同步方式，按commit順序同步，可能存在數據不一致 |
| Redis 的 AOF，每個操作室冪等的。 | |||
| MongoDB的oplog ，oplog中每個操作室冪等的 | |||
| 數據 | 保證數據一致性 | 數據量大 | Mysql的row模式 |
| 文件 | 保證生成文件時數據一致性 | 數據量大 | Redis的RDB |
| 複製的時候，數據可能有變化 |
複製方式
| 同步方式 | 特點 | 適用場景 |
|---|---|---|
| 同步 | 最強一致性 | 主備，主從架構 |
| 故障容忍度低 | ||
| 寫入性能低 | ||
| 異步 | 會出現，數據不一致 | 數據存儲集羣 |
| 故障容忍度高 | ||
| 寫入性能高 | ||
| 半同步 | 同步，異步的折中方案 | 數據存儲集羣 |
| 多數同步 | 數據一致性強 | 例如要求，分佈式一致性 |
| 故障容忍度高 | 例如：OceanBase | |
| 寫入性能低，實現複製 | ||
| 最強高可用 |
狀態決策
| 決策方式 | 特點 | 適用場景 |
|---|---|---|
| 依靠決策者（利用zookeepr等） | 決策簡單 | 大多數業務 |
| 數據一致性中等 | ||
| 決策者本身高可用複雜 | ||
| 協商式 | 一般採用雙通道，心跳機制 | 內部系統，網絡設備 |
| 數據一致性弱 | ||
| 標準算法式 | 決策過程複雜，一般採用標準算法 Raft，ZAB，Paxos等 | 餘額，庫存，或金融場景 |
| 數據一致性最強 | ||
| 可用性最高，一般使用quorum 防止腦裂 |
Redis Sentinel 分析
下圖，是Redis，Sentinel 的架構圖圖：
Sentinel 是決策者， master 是主庫，follow 是從庫，下面按照數據複製，狀態決策2個角度進行分析
數據複製
複製格式
AOF 命令
redis是先寫內存，後寫AOF日誌，不阻塞寫操作
同步到磁盤的策略
- Always同步寫盤, 性能差， 可靠性高，數據基本不丟失。
- Everysec每秒寫盤，性能適中，宕機損失1秒數據
- no操作系統控制寫盤，性能高，宕機損失數據多
AOF 重寫 針對AOF文件大，redis優化方式
- 後臺fork子進程 bgrewriteaof 來完成，不會阻塞主線程
- 使用AOF緩衝,AOF 重寫緩衝,保證在重寫過程中，新寫入的數據不會丟失
- 內存頁表越大，fork阻塞時間越久
複製方式
- 異步
- wait命令 實現半同步，
注：
Redis的WAIT命令,可確保指定數量的Redis副本已確認
在故障切換期間，已確認的寫入可能會丟失，取決於Redis持久性的配置
狀態決策，決策者：sentinel
Sentinel 作用
監控
- 週期性的給所有主從庫發送PING命令，檢查它們是否仍然在線運行
- 主觀下線，一個哨兵判斷主庫下線
- 客觀下線，大於等於quorum(降低集羣網絡壓力大，主庫壓力大造成的誤判的概率)，都判斷主庫已經主觀下線了，主庫才被標記客觀下線，開啓主從切換
選主(篩選+3輪打分)
篩選
down-after-milliseconds * 10 以內的作爲候選主庫
down-after-milliseconds 主從庫斷連的最大連接超時時間。超過10倍，認爲該候選庫網絡不好，剔除
打分
- 從庫優先級，slave-priority配置
- 從庫複製進度，
slave_repl_offset越接近master_repl_offset得分越高
master_repl_offset，master寫入的點位
slave_repl_offset 從庫複製的點位
- 從庫的ID號，號小的得分高
通知
讓從庫執行replicaof，與新主庫同步
通知client 連接新的主庫
Sentinel Leader 選舉流程
Raft 協議的實現，大致流程如下：
- 哨兵給其他哨兵發送命令，表明希望由自己成爲leader，並讓所有其他哨兵進行投票
- 每個哨兵選自己，並且根據先到先得的規則，接受/拒絕其他哨兵成爲leader的請求
- 作爲Leader的2個條件 拿到半數以上的贊成票 ，拿到的票數還要大於等於quorum
注意：每個哨兵的quorum 和 down-after-milliseconds 必須一樣