CAP 与 BASE
在说高可用之前，先来说说 CAP 理论，即：
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
CAP 理论是在涉及读写操作的场景下的理论，而不是分布式系统的所有功能。
一致性只需要保障客户端读操作能读到最新的写操作结果，并不要求时时刻刻分布式系统的数据都是一致的，这是不现实的，只要保障客户读到的一致即可。
可用性要求非故障的节点在合理的时间内能返回合理的响应，所谓合理是指非错误、非超时，即使数据不是最新的数据，也是合理的“旧数据”，是符合可用性的。
分区容错性要求网络分区后系统能继续履行职责，不仅仅要求系统不宕机，还要求能发挥作用，能处理业务逻辑。比如接口直接返回错误其实也代表系统在运行，但却没有履行职责。
在分布式系统下，P（分区容忍）是必须选择的，否则当分区后系统无法履行职责时，为了保障 C（一致性），就要拒绝写入数据，也就是不可用了。
在此基础上，其实我们能选择的只有 C+P 或者 A+P，根据业务特性来选择要优先保障一致性还是可用性。
在选择保障策略时，有几个需要注意的点：
CAP 关注的其实是数据的粒度，而不是整个系统的粒度，因此对于系统内的不同数据（对应不同子业务），其实是可以按照业务特性采取不同的 CAP 策略的。
CAP 实际忽略了网络延迟，也就是允许数据复制过程中的短时间不一致，如果某些业务比如金融业务无法容忍这一点，那就只能对单个对象做单点写入，其他节点备份，无法做多点写入。但对于不同的对象，其实可以分库来实现分布式。
当没有发生分区现象时，也就是不用考虑 P 时，上述限制就不存在，此时应该考虑如何保障 CA。
当发生分区后，牺牲 CAP 的其中一个并不代表什么都不用做，而是应该为分区后的恢复 CA 做准备，比如记录分区期间的日志以供恢复时使用。
伴随 CAP 的一个退而求其次，也更现实的追求，是 BASE 理论，即基本可用，保障核心业务的可用性；软状态，允许系统存在数据不一致的中间状态；最终一致性，一段时间后系统应该达到一致。
FMEA 分析法
要保障高可用，我们该怎么下手呢？俗话说知己知彼才能有的放矢，因此做高可用的前提是了解系统存在怎样的风险，并且还要识别出风险的优先级，先治理更可能发生的、影响更大的风险。说得简单，到底怎么做？业界其实已经提供了排查系统风险的基本方法论，即 FMEA（Failure mode and effects analysis）——故障模式与影响分析。
FMEA 的基本思路是，面对初始的架构设计图，考虑假设其中某个部件发生故障，对系统会造成什么影响，进而判断架构是否需要优化。
除了 FMEA，其实还有一种应用更广泛的风险分析和治理的理论，即 BCP——业务连续性计划，它是一套基于业务规律的规章流程，保障业务或组织在面对突发状况时其关键业务功能可以持续不中断。
相比 FMEA，BCP 除了评估风险及重要程度，还要求详细地描述应对方案、残余风险、灾备恢复方案，并要求进行相应故障的培训和演习安排，尽最大努力保障业务连续性。
知道风险在哪、优先治理何种风险之后，就可以着手优化架构。和高性能架构模式一样，高可用架构也可以从存储和计算两个方面来分析。
