高可用的关键指标
问题：分为故障跟灾难。不是有了多活架构就不在用复制架构 ，还是之前的合适原则：多活架构的技术复杂度 跟成本都比复制架构高。
高可用的关键指标
恢复时间目标(RecoveryTimeObjective，RTO)指为避免在灾难发生后业务连续性中断带来不可接受的结果而使业务流程必须恢复的最早时间期限和服务水平，RTO通常指使得基础设施和系统恢复运行的时间。
恢复点目标(RecoveryPointObjective，RPO)指最大可容忍的数据丢失量，用时间来衡量，这个值代表着数据必须恢复的最早时间点，数据量越大，意味着要投入的资金或者其他资源越多，才能确保在灾难事件中损失的数据越少。
最大允许中断时间(MTD )=RTO+ WRT
工作恢复时间(WorkRecoveryTime，WRT)指系统恢复正常后，恢复业务所需要的时间 ，因为要进行各种业务检查、校验、修复。
主备复制与主从复制
本质：通过冗余来提升可用性，通过叠加来提升读性能
变化：备机是否提供复制源功能，备机部署地点，主从主备混合部署
优点：实现简单，只需要数据复制，无状态检测和角色切换
缺点：需人工干预，RTO比较大
主备级联复制
变化：备机作为复制源，例如图中备机1就是备机2的复制源
优点：主机故障后，切换备机1为主机，方便快捷，直接修改配置即可，无需修改备机2的配置，无需判断备机1和备机2的数据覆盖问题
缺点：备机1对备份非常关键，备机1宕机会导致两台备份机都备份失效
应用：MySQL、Redis支持这种模式
实际情况下，很少有 团队采用这种方案，这种方案优点减轻多个备机读取主机压力，减轻压力有限，还不如分库分表更实用，此处仅做用对比学习。
主备架构的灾备部署
场景1：IDC-1和IDC-2在同一个城市，可以应对机房级别的灾难
场景2：IDC-1和IDC-2不在同一个城市，可以应对城市级别的灾难
变种：主从架构的灾备部署
场景1：IDC-1 和 IDC-2 在同一个城市，可以应对机房级别的灾难
场景2：IDC-1 和 IDC-2 不在同一个城市，可以应对城市级别的灾难
这里，为啥不把IDC-2的备机改为从机提供读取服务，考虑跨城市的延迟较大。
案例，redis 的模式有主从，主从是client负责的调用。
双机切换架构
主备切换：复杂度很高
优点：可以自动实现故障恢复，RTO短
缺点：实现复杂，需要实现数据复制、状态检测、故障切换、数据冲突处理
应用：内部系统、管理系统（数据量小，业务容忍度高）
主从切换
整体和主备切换类似，差异点在于“切换阶段”，只有主机提供读写服务，主机性能有风险，数据量高情况有可能扛不住。
集群选举架构
优点：可以自动实现故障恢复、RTO短，可用性更高
缺点：实现复杂，需要实现数据复制、状态检测、选举算法、故障切换、数据冲突处理
应用：应用广泛，例如Redis、MongoDB等
案例：
bully\raft\zab\paxos
最佳实践-基于ZooKeeper实现
基于ZooKeeper来实现双机切换或者集权选举，能够大大降低复杂度，优势有如下几点：
- ZooKeeper已经保证了自我的高可用
- 基于ZooKeeper，切换或选举过程实现比较简单
- ZooKeeper可以有多用途
这里李老师只是普及下，没有深入的展开去讲。es 的7版本后，也有不同于之前的bully算法。这块有待梳理。
