如何设计高可用架构笔记

AI之道
447 阅读6分钟

目标：

  1. 理解高可用架构的复杂度本质
  2. 掌握高可用架构分析和设计

鸡蛋篮子法则（冗余法则）：不要把所有鸡蛋都放到同一个篮子，放到多个篮子！

一、高可用复杂度模型

1.1 高可用复杂度模型

image.png

谈到高可用，首先想到计算高可用和存储高可用，计算高可用主要有两个维度，一是任务分配，一是任务分解；

数据复制，高可用存储架构需要把数据从一个服务器复制到另一台服务器，涉及到复杂的格式与方式；

状态决策，高可用架构需要判断故障的状态，然后进行一些比如说主备切换、集群选主的一些操作，可以有很多方式，独裁式、协商式、民主式；

不同的架构场景和技术，底层上用到的技术类似；

高性能架构分为单机高性能和集群高性能，为何高可用架构没有单机高可用？

  • 高可用和高性能本质上是有区别的
  • 高可用是通过冗余来实现的，一旦冗余至少是两台以上
  • 高性能单机也可以做到很高的性能

鸡蛋篮子理论第三法则 - 冗余法则

image.png

一个篮子不保险，避免出现极端风险出现，用三个篮子装鸡蛋，就算一个篮子掉了坏了，它也只是损失一部分鸡蛋

鸡蛋是篮子理论第三法则（冗余法则）：不要把所有鸡蛋装在一个篮子，放到多个篮子。

1、可扩展，拆分法则

2、高性能，叠加法则

3、高可用，冗余法则；高可用方案必然是集群方案

二、计算高可用 - 任务分配

2.1 计算高可用复杂度模型

image.png

2.2 任务分配 - 分析

image-20230422232448852.png

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

复杂度分析

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

高性能任务分配考虑的是正常处理，高可用任务分配考虑的是异常处理

2.3 任务分配 - 架构设计关键点

image-20230422232821498.png

2.4 任务分配 - 案例

image-20230422233302096.png

计算高性能架构，一定就是计算高可用架构么？

  • Nginx可以算是计算高可用的架构
  • DNS和Memcached不算是高可用的架构，因为它们不会去检测服务器是否正常的能力的

三、计算高可用 - 任务分解

3.1 任务分解 - 分析

image.png

任务分解，将服务器拆分为不同角色，不同服务器处理不同的业务。

复杂度分析

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

任务分解避免业务互相影响，保证局部可靠性。

3.2 任务分解 - 架构设计关键点

image-20230422233553970.png

3.3 任务分解 - 案例

image-20230422233623993.png

架构模式

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

四、存储高可用 - 数据复制

4.1 存储高可用复杂度模型

image-20230422234124350.png

存储高可用的核心关键点就是两个，数据复制和状态决策，数据复制就是怎么把数据从A服务器复制到B服务器；状态决策就是怎么判断A服务器正常还是B服务器正常，如果不正常该怎么做

模型可以深化出多少种架构？

  1. 这是一个简单的算术题
  2. 3 * 4 * 3 = 36种

4.2 数据复制 - 格式

image-20230422235449491.png

【复制命令】

优缺点

  1. 实现简单，复制数据量小
  2. 数据可能不一致（SQL函数）

适应场景，增量复制

【复制数据】

  1. 实现简单
  2. 保证数据一致
  3. 复制流量可能会很大

适应场景，增量复制

【复制文件】

  1. 实现复杂，复制的时候数据在变
  2. 保证数据一致
  3. 复制流量可能会很大

适应场景，全是复制

4.3 数据复制 - 方式1

image-20230423003139972.png

【同步复制】

优缺点

  1. 最强一致性，故障容忍度低
  2. 写入性能低

适应场景

  1. 主备/主从架构

【异步复制】

优缺点

  1. 写入性能高，故障容忍度高
  2. 容易出现数据不一致

适应场景

  1. 数据存储集群

4.4 数据复制 - 方式2

image-20230423003618978.png

【半同步复制】

半同步复制，先挑选一台服务器进行复制，只要这一台服务器复制成功就返回客户端成功，然后再通过异步方式两步给其他服务器。

优缺点

  1. 同步复制和异步复制的折衷方案

适应场景，数据存储集群

【多数复制】

什么叫做多数复制，为了能够保证数据一致性跟可靠性，把数据不是复制到一台服务器，而是复制到多数服务器（5个节点至少3个，7个节点至少4个）

优缺点

  1. 数据强一致性，最高可用性，故障容忍度高。
  2. 写入性能不高，实现复杂。一般需要算法来支撑，比如说像Paxos算法和Raft算法

适用场景，分布式一致性、分布式协同（OceanBase、ZooKeeper）

4.5 数据复制 - 案例

image-20230423010541434.png

【Redis】

  1. 复制格式：命令（AOF）+ 文件（RDB）
  2. 复制方式：异步 + wait（指定半同步）

image-20230423010442768.png

【MySQL】

  1. 复制格式：命令（statement）+ 数据（Row）
  2. 复制方式：异步 + 半同步

五、存储高可用 - 状态决策

5.1 状态决策 - 独裁式

image-20230423012321516.png

【优缺点】

  1. 决策逻辑简单
  2. 决策者要做到高可用，整体架构复杂，常用ZooKeeper/Raft/Keepalived
  3. 数据一致性强度中等

【应用场景】 绝大部分业务都可以应用

5.2 状态决策 - 协商式

image-20230423013032498.png

【优缺点】

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

【应用场景】 内部系统、网络设备（用串口相连）

5.3 状态决策 - 民主式/选举式

image-20230423013826705.png

【优缺点】

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

【应用场景】 对数据一致性要求很高的场景，例如余额、库存

六、总结 - 思维导图

image.png

avatar
文章
阅读
粉丝