复制架构解析

高可用的关键指标

在这里插入图片描述

在这里插入图片描述

  1. RPO(Recovery Point Objective),恢复点目标,指“最大可接受的数据损失”,因为数据备份和复制都是有时间限制的,不可能做到绝对实时
  2. RTO(Recovery Time Objective),恢复时间目标,指“最大可接受的系统恢复所需时间”,因为定位、处理、恢复都需要时间
  3. WRT(Work Recovery Time),工作恢复时间,指“系统恢复正常后,恢复业务所需要的时间”,因为要进行各种业务检查、校验、修复
  4. 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来实现双机切换或者集权选举,能够大大降低复杂度,优势有如下几点:

  1. ZooKeeper已经保证了自我的高可用
  2. 基于ZooKeeper,切换或选举过程实现比较简单
  3. ZooKeeper可以有多用途
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值