【NOTE】高可用架构-CAP理论和FMEA

# 【从 0 学架构】高可用架构-CAP 理论和 FMEA

# CAP 理论(布鲁尔理论)和细节

# 什么是 CAP 理论?

CAP 理论目前有两版,第二版更精确,两版之间比较如下:

第一版 第二版 区别
CAP 对于一个分布式计算系统,不可能同时满足一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三个设计约束。 在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。 第二版细化了互联和共享数据的分布式系统,例如 mysql 集群需要互联和复制。同时强调只关注读写操作。
一致性(Consistency) 所有节点在同一时刻都能看到相同的数据。 对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。 对于节点来说,同一时刻可以用不同数据。例如对于事务执行未提交前,不同节点数据不完全一致。
可用性(Availability) 每个请求都能得到成功或者失败的响应。 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)
分区容忍性(Partition Tolerance) 出现消息丢失或者分区错误时系统能够继续运行 当出现网络分区后,系统能够继续“履行职责”。 丢包、连接中断、拥塞都可能导致网络分区。第二版情况更广泛。

CAP 关注的粒度是「数据」,而不是系统。也就是说,同一个系统中,针对不同的数据,不同数据各自有不同的 CAP 架构选择。
例如对于用户管理系统,用户账号密码(核心数据)选择 CP,用户信息(年龄、住址)选择 AP。

而对于一些特殊的金融场景,例如用户余额或者抢购。由于物理网络有延迟,是无法做到分布场景下“完美一致性”。理论上应该是 CP,但其实是 CA,单点写入,其他节点备份数据。

# CP 和 AP

既然无法保证 CAP,那么可以保证 C、A、P 其中 2 个。在分布式下,网络无法 100%可靠,所以要做到 P。

考虑分区情况下,只能选择 CP 架构、AP 架构。不发生分区时,可以做到 CA(例如上面说的金融场景)。

CP 架构

  • N1 和 N2 连接中断,网络分区
  • 数据无法从 N1 同步到 N2
  • 访问 N2 要返回 ERROR,防止出现数据不一致,满足一致性
  • 由于访问 N2 返回 ERROR,所以不满足可用性

AP 架构:

  • N1 和 N2 连接中断,网络分区
  • 数据无法从 N1 同步到 N2
  • 访问 N2 返回未同步数据,满足可用性
  • N1 数据没同步到 N2,不满足一致性

# BASE:AP 架构的扩展

BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性

分布式系统的初衷是:横向扩展、高可用。前者解决单点性能瓶颈,但会带来分区情况出现;而后者是分布式核心诉求。所以设计上尽量满足 AP,而数据一致性可以通过备份或者业务逻辑策略来满足。

# FMEA:故障模式与影响分析

理论很有意思,应用于各个行业,FMEA 是一套分析和思考的方法,而不是某个领域的技能或者工具。

它的作用是对设计好的架构进行分析,排查架构的可用性隐患。

FMEA 方法论:

  • 假设:某个部分发生故障
  • 分析:对系统的影响
  • 措施:判断是否需要优化

案例:用户系统,包含登录和注册

FMEA 表:

改进: