高可用的关键指标
- RPO(Recovery Point Objective),恢复点目标,指“最大可接受的数据损失”,因为数据备份和复制都是有时间限制的,不可能做到绝对实时
- RTO(Recovery Time Objective),恢复时间目标,指“最大可接受的系统恢复所需时间”,因为定位、处理、恢复都需要时间
- WRT(Work Recovery Time),工作恢复时间,指“系统恢复正常后,恢复业务所需要的时间”,因为要进行各种业务检查、校验、修复
- MTD(Maximum Tolerable Downtime),最大可容忍宕机时间,等于RTO+WRT
主备&主从架构
主备复制&主从复制
本质:通过冗余来提升可用性,通过叠加来提升读性能
变化:备机是否提供复制功能,备机部署地点,主从主备混合部署
优点:实现简单,只需要数据复制,无状态检测和角色切换
缺点:需人工干预,RTO比较大
变种1:主备级联复制
变化:备机作为复制源,例如图中备机1就是备机2的复制源
优点:主机故障后,切换备机1为主机,方便快捷,直接修改配置即可,无需修改备机2的配置,无需判断备机1和备机2的数据覆盖问题
缺点:备机1对备份非常关键,备机1宕机会导致两台备份机都备份失效
应用:MySQL、Redis支持这种模式
变种2:主备架构的灾备部署
场景1:IDC-1和IDC-2在同一个城市,可以应对机房级别的灾难
场景2:IDC-1和IDC-2不在同一个城市,可以应对城市级别的灾难
变种3:主从架构的灾备部署
场景1:IDC-1 和 IDC-2 在同一个城市,可以应对机房级别的灾难
场景2:IDC-1 和 IDC-2 不在同一个城市,可以应对城市级别的灾难
双机切换架构
主备切换
优点:可以自动实现故障恢复,RTO短
缺点:实现复杂,需要实现数据复制、状态检测、故障切换、数据冲突处理
应用:内部系统、管理系统
主从切换
整体和主备切换类似,差异点在于“切换阶段”,只有主机提供读写服务,主机性能有风险
集群选举架构
优点:可以自动实现故障恢复、RTO短,可用性更高
缺点:实现复杂,需要实现数据复制、状态检测、选举算法、故障切换、数据冲突处理
应用:通用,例如Redis、MongoDB等
案例
Redis
使用sentinel集群来解决“决策者”单点问题,sentinel又是通过Raft算法进行选举的
MongoDB
3.2之前是Bully选举算法(ES也是用这个),3.2之后改为Raft算法
最佳实践-基于ZooKeeper实现
基于ZooKeeper来实现双机切换或者集权选举,能够大大降低复杂度,优势有如下几点:
- ZooKeeper已经保证了自我的高可用
- 基于ZooKeeper,切换或选举过程实现比较简单
- ZooKeeper可以有多用途