存儲高可用，一般采用複制架構，複制架構，需要關注故障架構和狀态決策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 必須一樣