1 CAP理论
1.1 第一版定义
对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束。
一致性：：所有节点在同一时刻都能看到相同的数据。
可用性：每个请求都能得到成功或者失败的响应。
分区容错性：出现消息丢失或者分区错误时系统能够继续运行。
1.2 第二版定义
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
例如Memcache 的集群，相互之间就没有连接和共享数据，因此Memcache 集群这类分布式系统就不符合 CAP 理论探讨的对象；
而 MySQL 集群就是互联和进行数据复制的，因此是 CAP 理论探讨的对象，Redis也是
第二版的CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。例如，ZooKeeper 的选举机制就不是 CAP 探讨的对象。
一致性：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
可用性：非故障的节点在合理的时间内返回合理的响应（错误和超时的响应不算合理）。
分区容错性：当出现网络分区后，系统能够继续“履行职责”。
1.3 选择
因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。
如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。
因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
2 CAP细节
- 细节1：CAP 关注的粒度是数据，而不是整个系统。
一个系统有的数据必须选择 CP，有的数据必须选择 AP，因此不同数据可以选择不同的点
- 细节2：CAP是忽略网络延迟的，但实际上是存在的
技术上是无法做到分布式场景下完美的一致性的。
而业务上必须要求一致性，因此单个用户的余额、单个商品的库存，理论上要求选择 CP 而实际上 CP 都做不到，只能选择 CA。
也就是说，只能单点写入，其他节点做备份，无法做到分布式情况下多点写入。
也因为有此细节的存在，因此CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
-
细节3：正常运行情况下，不存在 CP 和 AP 的选择，即不用满足P，所以可以同时满足 CA。
-
细节4：放弃并不等于什么都不做，需要为分区恢复后做准备。
分区期间放弃 C 或者 A，并不意味着永远放弃 C 和 A，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到 CA 的状态。
比如在分区期间记录一些日志，当分区故障解决后，系统根据日志进行数据恢复，使得重新达到 CA 状态。
3 BASE
BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充，系统在分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性，这样也可以让CAP变得更加完美
4 FEMA方法
FMEA 方法是保证做到全面分析系统可用性的一个非常简单但是非常有效的方法。
FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等
通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。
FMEA 并不能指导我们如何做架构设计，而是当我们设计出一个架构后，再使用 FMEA 对这个架构进行分析，看看架构是否还存在某些可用性的隐患。
4.1 具体分析方法
给出初始的架构设计图。
假设架构中某个部件发生故障。（所有部件都要假设）
分析此故障对系统功能造成的影响。
根据分析结果，判断架构是否需要进行优化。
FMEA 会列出一个分析表格，包含的内容为：业务功能点、故障模式/现象、故障影响、严重程度、故障原因、某个具体故障原因发生的概率、硬件、开源系统、自研系统、风险程度、已有措施、规避措施、解决措施、后续规划
表格中的描述要尽量精确，多使用量化描述，避免使用泛化的描述，比如尽量给出数据