1. 高可用关键指标
1.1 存储类问题处理
·故障：目的是可用、可恢复；手段是复制架构；责任人是研发
·灾难：目的是可用；手段是多活架构；责任人是研发
·备份：目的是可恢复；手段是备份；责任人是运维
1.2 高可用存储几个核心指标
·RPO (Recovery Point Objective)：恢复点目标，指"最大可接受的数据丢失"，因为数据备份和复制都是有时间窗制的，不可能实现对实时。
·RTO (Recovery Time Objective)：恢复时间目标，指"最大可接受的系统恢复所需时间"，因为定位、处理、恢复需要时间。
·WRT (Work Recovery Time)：工作恢复时间，指"系统恢复正常后，恢复业务所需的时间"，因为要进行各种业务检查、校验、修复。
·MTD (Maximum Tolerable Downtime)：最大可容忍停机时间，等于RTO + WRT。
2. 主备 & 主从架构
2.1 主备复制 & 主从复制
·主备复制（数据可恢复）：
本质：通过冗余来提升可用性，通过增加备机提升性能。
变化：备机是否提供只读功能，备机部署地点，主从主备混合部署。
优点：实现简单，只需要数据复制，无状态检测和角色切换。
缺点：需要人工干预，RTO比较大。
·主从复制（数据可恢复 + 高性能读）：
优点：实现简单，只需要数据复制，无状态检测和角色切换。
缺点：需要人工干预，RTO比较大。
2.2 主备级联复制
·变化：备机作为复制源
·优点：主机故障后，切换备机1为主机，方便快速，直接修改配置即可（即中继故障）；无需修改备机2的配置，无需对新备机1和备机2的数据重置问题。
·缺点：备机1对备机2来说是复制源，备机1与机2会导致两者备份机都会有延迟。
·应用：MySQL、Redis支持这种模式。
2.3 主备架构的灾备部署
·场景1：IDC-1和IDC-2在同一个城市，可以应对机房级别的灾难。
·场景2：IDC-1和IDC-2不在同一个城市，可以应对城市级别的灾难。
2.4 主从架构的灾备部署
·场景1：IDC-1和IDC-2在同一个城市，可以应对机房级别的灾难。
·场景2：IDC-1和IDC-2不在同一个城市，可以应对城市级别的灾难。
3. 双机切换架构
3.1 双机切换 - 主备切换
·正常运行：业务服务器读写主机，主机数据复制到备机
·切换阶段：主机（旧）故障，主机（新）接管
·恢复阶段：备机（新）接管，主机（新）正常工作
·优点：可以自动实现故障恢复，RTO短。
·缺点：实现复杂，需要实现数据复制，状态检测，故障切换，数据冲突处理。
·应用：内部系统、管理系统。
3.2 双机切换 - 主从切换
·正常运行：业务服务器读写主机，主机数据复制到从机
·切换阶段：主机（旧）故障，主机（新）接管
·恢复阶段：从机（新）接管，主机（新）正常工作
·整体和主备切换类似，差异点在于"切换阶段"，只有主机提供读写服务，主机性能有风险。
4. 集群选举架构
4.1 集群选举
·正常运行：业务服务器读写主机，主机数据复制到备机
·选举：主机(旧)故障，主机(新)被选举
·优点：可以自动实现故障恢复，RTO短，可用性更高。
·缺点：实现复杂，需要实现数据复制，状态检测，选举算法，故障切换，数据冲突处理。
·应用：通用，例如Redis、MongoDB等。
4.2 集群选举案例 - Redis & MongoDB
·Redis：使用sentinel集群实现，"决策者"单点问题，sentinel又是通过Raft算法运行的集群。
·MongoDB：3.2前用Bully选举算法（ES也是用这个），3.2后改为Raft算法。
5. 最佳实践 - 基于ZooKeeper实现
基于ZooKeeper实现双机切换或者集群选举，能够大大降低复杂度，优势有几点：
1. zookeeper已经保证了自身的高可用
2. 基于ZooKeeper，切换或者选举通过程序实现比较简单
3. ZooKeeper可以有多种用途