《从0开始学架构》——高可用：CAP理论和FMEA方法

本系列是极客时间《从0开始学架构》的读书笔记。

接下来就是高可用部分了。

一般来讲，相对于高性能来说，高可用的复杂度更高，因为高可用的异常情况太多，只要稍有疏漏，就会埋下隐患。当然只是对一般情况而言。

对于高性能来讲，有一种方法是采用集群，来将海量请求分发到不同的机器上，从而提高性能。相对应的，高可用也可采用集群，来避免单点出现故障时，服务不可用。总结下，高可用场景下采用集群的原理是增加了冗余。

一般称这种集群为分布式系统。
分布式系统可横向扩展，是为了解决单点瓶颈问题，提高高并发量下的可用性（依我看，就是高性能集群的应用场景，当然问题角度不同）。
分布式系统还可保证高可用性，是为了解决单点故障问题，保证部分节点出现问题时服务依然可用。

以下的内容都是对于上述第二点而言的。

高可用集群的复杂度表现在数据延迟和数据的一致性两方面。CAP理论就是关于数据一致性的。

一、CAP

对应《22 | 想成为架构师，你必须知道CAP理论》《23 | 想成为架构师，你必须掌握的CAP细节》

CAP定理，又称布鲁尔定理，是设计分布式系统时必须掌握的理论。

C：Consistency，一致性，A：Availability，可用性，P：Partition tolerance，分区容错性。

CAP理论

1.在一个分布式系统（互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证满足CAP中的三者之二。
关键点是，首先对分布式系统的定义作了限制，如果不互联或不共享数据的分布式系统，则不适合CAP理论。另一个是关注的是数据的读写操作，不关注其它功能。

2.Consistency，一致性，指的是，对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
Availability，可用性，指的是，非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。注意并没有说“正确”的响应。
Partition tolerance，分区容忍性，指的是，当出现网络分区后，系统能够继续“履行职责”。

CAP应用

在分布式系统中，分区总是不可避免的，所以必须选择P，只能是CP或AP。如果是CA的话，当出现分区时，若要保证C，则系统需要禁止写入，当写入请求时，系统返回的响应不合理，违背A。反过来要保证A，就会违背C。

CAP细节

1.CAP关注的的粒度是数据，不是系统。也就是说，在设计分布式系统的时候，对于整个系统，其实并不限定一定是CP或AP。对于不同的数据，会选择不同的组合。
2.CAP是忽略网络延时的。这意味着，C在实践中是不可能完美实现的，由于存在网络时延，导致在数据复制过程中，可能存在不一致现象。所以理论上选择CP，而CP都做不到，这时只能选择CA。即分布式情况下，只做到单点写入，其他节点做备份，做不到多点写入。
3.正常情况下，不存在CP或AP，则可满足CA。按照CAP理论，在出现分区时只能选择CP或AP，但是系统没有分区时，就可以考虑CA。也就是说在设计分布式系统时，既要考虑在分区出现时选择CP还是AP，也要考虑正常情况下如何保证CA。
4.放弃不等于什么都不做，需要为分区后恢复做准备。

其他数据一致性理论

ACID是数据库管理系统（DBMS）为保证事务的正确性，而提出的理论。其中I隔离性又可分为读未提交、读提交、可重复读、串行化。
ACID关注的是数据库事务，而CAP关注的是分布式系统中数据的读写。

BASE，指的是，基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency），即系统无法做到强一致性（CAP中的C），但可以通过适合的方式做到最终一致性。
可见，BASE理论是CAP理论的延伸和补充。更具体的是，对AP方案的一个补充，因为主要是对一致性作了补充定义。
由于时延，所以完美CP不存在。所以CP方案实际上是实现了最终一致性。
AP方案牺牲了C，但是只是在分区时牺牲了一致性，当分区故障恢复后，还是要保证最终一致性。

谈点个人的感受。第一次看CAP理论时，我有点晕。在看完整个课程后再来看，还是发现能够和之后所讲的内容有所印证。但是由于实际上缺少真正的架构设计经验，对于CAP理论还是未能完全掌握。

二、FMEA

对应《24 | FMEA方法，排除架构可用性隐患的利器》

既然高可用架构很难设计，复杂度很高，那怎么才能保证设计时能够考虑到所有的异常情况呢？

FMEA，故障模式与影响分析。

具体分析方法是：
1.给出初始的设计架构图。
2.假设架构中的某个部件发生故障。
3.分析此故障对系统的影响。
4.根据分析结果，确定是否需要对架构做优化。

在一个FMEA表格中，需要包含：
1.功能点。是从用户角度来看的。
2.故障模式。故障功能点加故障模式，只需要描述现象即可。
3.故障影响。功能点会受到什么影响，描述尽量准确，但不需要很精确。
4.严重程度。站在业务的角度，会受到的影响程度。
5.故障原因。
6.故障概率。
7.风险程度。综合严重程度和故障概率，来最终判断一个故障的等级。
8.已有措施。
9.规避措施。
10.解决方案。
11.后续规划。