如何设计高可用架构

高可用复杂度模型

如何设计高可用架构_第1张图片

计算高可用

任务分配

如何设计高可用架构_第2张图片

将任务分配给多个服务器执行

复杂度分析

  1. 增加“任务分配器”节点,可以是独立的服务器,也可以是SDK
  2. 任务分配器需要管理所有的服务器,可以通过配置文件,也可以通过配置服务器(例如Zookeeper)
  3. 任务分配器需要根据不同的需求采用不同的算法分配
  4. 任务分配器需要监控业务服务器的状态,在故障时进行切换

任务分配架构设计关键点

如何设计高可用架构_第3张图片

案例

如何设计高可用架构_第4张图片

任务分解

如何设计高可用架构_第5张图片

将服务拆分为不同角色,不同服务器处理不同的业务

复杂度分析

  1. 增加“任务分解器”节点,可以是独立的服务器,也可以是SDK
  2. 任务分解器需要管理所有的服务器,可以通过配置文件,也可以通过配置服务器(例如Zookeeper)
  3. 需要设计任务拆分的方式,任务分解器需要记录“任务”和“服务器”的映射关系
  4. 任务分配器需要根据不同的需求采用不同的算法分配
  5. 任务分解器需要监控业务服务器的状态,在故障时进行切换

任务分解架构设计关键点

如何设计高可用架构_第6张图片

案例-微信服务拆分

如何设计高可用架构_第7张图片

架构模式

  1. 按照业务逻辑划分服务器集群
  2. 独立的接入服务器

存储高可用

复杂度模型

如何设计高可用架构_第8张图片

数据复制

复制格式

复制命令

如何设计高可用架构_第9张图片

优缺点
  1. 实现简单,复制数据量小
  2. 数据可能不一致(SQL函数)
适用场景

增量复制

复制数据

如何设计高可用架构_第10张图片

优缺点
  1. 实现简单
  2. 保证数据一致
  3. 复制流量可能会很大
适用场景

增量复制

复制文件

如何设计高可用架构_第11张图片

优缺点
  1. 实现复杂,复制的时候数据在变
  2. 保证数据一致
  3. 复制流量可能会很大
适用场景

全量复制

复制方式

同步复制

如何设计高可用架构_第12张图片

优缺点
  1. 最强一致性,故障容忍度低
  2. 写入性能低
适应场景

主备/主从架构

异步复制

如何设计高可用架构_第13张图片

优缺点
  1. 写入性能高,故障容忍度高
  2. 容易出现数据不一致
适应场景

数据存储集群

半同步复制

如何设计高可用架构_第14张图片

优缺点

同步复制和异步复制的折中方案

适应场景

数据存储集群

多数复制

如何设计高可用架构_第15张图片

优缺点
  1. 数据强一致性,最强可用性,故障容忍度高
  2. 写入性能不高,实现复杂
适应场景

分布式一致性、分布式协同

案例

Redis

如何设计高可用架构_第16张图片

复制格式:命令(AOF)+文件(RDB)

复制方式:异步+wait(指定半同步)

MySQL

如何设计高可用架构_第17张图片

复制格式:命令(statement)+数据(Row)

复制方式:异步+半同步

状态决策

方式

独裁式

如何设计高可用架构_第18张图片

优缺点
  1. 决策逻辑简单
  2. 决策者要做到高可用,整体架构复杂,常用Zookeeper、Raft、Keepalived
  3. 数据一致性强度中等
应用场景

绝大部分业务都可以应用

协商式

如何设计高可用架构_第19张图片

优缺点
  1. 架构实现简单,决策逻辑简单,一般是心跳机制
  2. 如果是链路问题,会导致双主,可以用双通道来缓解
  3. 数据一致性弱
应用场景

内部系统

民主式/选举式

如何设计高可用架构_第20张图片

优缺点
  1. 决策过程复杂,决策逻辑复杂,一般用标准算法进行选举,例如Raft、ZAB、Paxos
  2. 可用性最高,数据一致性最强
  3. 可能出现“脑裂”问题,可以采用quorum来控制
应用场景

对数据一致性要求很高的场景,例如余额、库存

案例

独裁式
Redis

如何设计高可用架构_第21张图片

使用Sentinel集群来解决“决策者”单点问题,sentinel又是通过Raft算法进行选举的

Hadoop

如何设计高可用架构_第22张图片

NameNode是集群决策者,使用Zookeeper集群来解决NameNode单点问题

民主式
Zookeeper

如何设计高可用架构_第23张图片

基于ZAB算法选举

MongoDB

如何设计高可用架构_第24张图片

3.2.0以前基于bully算法,3.2.0开始基于Raft算法

你可能感兴趣的:(架构,架构)