ＣＡＰ理论：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

CAP 关注的粒度是数据，而不是整个系统。

CAP 是忽略网络延迟的。

正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。

放弃并不等于什么都不做，需要为分区恢复后做准备。

ACID 是数据库管理系统为了保证事务的正确性而提出来的一个理论，ACID 包含四个约束

Atomicity（原子性）一个事务中的所有操作，要么全部完成，要么全部不完成

Consistency（一致性）在事务开始之前和事务结束以后，数据库的完整性没有被破坏

Isolation（隔离性）数据库允许多个并发事务同时对数据进行读写和修改的能力

.Durability（持久性）事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

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

基本可用（Basically Available）分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

软状态（Soft State）允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。

最终一致性（Eventual Consistency）系统中的所有数据副本经过一定时间后，最终能够达到一致的状态

BASE 理论本质上是对 CAP 的延伸和补充，是对 CAP 中 AP 方案的一个补充。前面在剖析 CAP 理论时，提到了其实和 BASE 相关的两点：CAP 理论是忽略延时的，而实际应用中延时是无法避免的。这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性

FMEA方法，排除架构可用性隐患的利器

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等

在架构设计领域，FMEA 的具体分析方法是：给出初始的架构设计图。假设架构中某个部件发生故障。分析此故障对系统功能造成的影响。根据分析结果，判断架构是否需要进行优化

高可用存储架构：双机架构

常见的双机高可用架构：主备、主从、主备 / 主从切换和主主

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等

主备复制架构的优点就是简单，

表现有：对于客户端来说，不需要感知备机的存在，即使灾难恢复后，原来的备机被人工修改为主机后，对于客户端来说，只是认为主机的地址换了而已，无须知道是原来的备机升级为主机。

对于主机和备机来说，双方只需要进行数据复制即可，无须进行状态判断和主备切换这类复杂的操作。

主备复制架构的缺点主要有：

备机仅仅只为备份，并没有提供读写操作，硬件成本上有浪费。故障后需要人工干预，无法自动恢复。

人工处理的效率是很低的，可能打电话找到能够操作的人就耗费了 10 分钟，甚至如果是深更半夜，出了故障都没人知道。

人工在执行恢复操作的过程中也容易出错，因为这类操作并不常见，可能 1 年就 2、3 次，实际操作的时候很可能遇到各种意想不到的问题。

主从复制和主备复制只有一字之差，“从”意思是“随从、仆从”，“备”的意思是备份。我们可以理解为仆从是要帮主人干活的，这里的干活就是承担“读”的操作。也就是说，主机负责读写操作，从机只负责读操作，不负责写操作

主从复制与主备复制相比，

优点有：主从复制在主机故障时，读操作相关的业务可以继续运行。

主从复制架构的从机提供读操作，发挥了硬件的性能。

缺点有：

主从复制架构中，客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理，复杂度比主备复制要高。主从复制架构中，从机提供读业务，如果主从复制延迟比较大，业务会因为数据不一致出现问题。故障时需要人工干预。

双机切换：

1. 设计关键 ：主备间状态判断：主要包括两方面：状态传递的渠道，以及状态检测的内容。状态传递的渠道：是相互间互相连接，还是第三方仲裁？状态检测的内容：例如机器是否掉电、进程是否存在、响应是否缓慢等。切换决策主要包括几方面：切换时机、切换策略、自动程度。数据冲突解决

2.常见的主备切换架构有三种形式：互连式、中介式和模拟式

主主复制：必须保证数据能够双向复制，而很多数据是不能双向复制的；主主复制架构对数据的设计有严格的要求，一般适合于那些临时性、可丢失、可覆盖的数据场景

高可用存储架构：集群和分区

根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群

1. 数据集中集群：主机如何将数据复制给备机，可能存在多通道，如何保证数据一致性；备机如何检测主机状态；主机故障后，如何决定新的主机

2. 数据分散集群：数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。算法需要考虑这些设计点：均衡性，容错性，可伸缩性

数据分区：数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上

数据分区架构，需要从多方面去考虑：1. 数据量2. 分区规则3. 复制规则：常见的分区复制规则有三种：集中式、互备式和独立式。

设计计算高可用架构

计算高可用的设计思想很简单：通过增加更多服务器来达到计算高可用。

计算高可用架构的设计复杂度主要体现在任务管理方面：计算高可用架构设计的关键点有下面两点

1. 哪些服务器可以执行任务 ：第一种方式和计算高性能中的集群类似，每个服务器都可以执行任务。例如，常见的访问网站的某个页面。第二种方式和存储高可用中的集群类似，只有特定服务器（通常叫“主机”）可以执行任务。当执行任务的服务器故障后，系统需要挑选新的服务器来执行任务

2. 任务如何重新执行

第一种策略是对于已经分配的任务即使执行失败也不做任何处理，系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。第二种策略是设计一个任务管理器来管理需要执行的计算任务，服务器执行完任务后，需要向任务管理器反馈任务执行结果，任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行

常见的计算高可用架构：主备、主从和集群。

主备方案的详细设计：主机执行所有计算任务。例如，读写数据、执行操作等。当主机故障（例如，主机宕机）时，任务分配器不会自动将计算任务发送给备机，此时系统处于不可用状态。如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续将任务发送给主机。如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将备机升为主机，然后让任务分配器将任务发送给新的主机（即原来的备机）；同时，为了继续保持主备架构，需要人工增加新的机器作为备机。根据备机状态的不同，主备架构又可以细分为冷备架构和温备架构

主从方案详细设计：正常情况下，主机执行部分计算任务（如图中的“计算任务 A”），备机执行部分计算任务（如图中的“计算任务 B”）。当主机故障（例如，主机宕机）时，任务分配器不会自动将原本发送给主机的任务发送给从机，而是继续发送给主机，不管这些任务执行是否成功。如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续按照原有的设计策略分配任务，即计算任务 A 发送给主机，计算任务 B 发送给从机。如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将原来的从机升级为主机（一般只是修改配置即可），增加新的机器作为从机，新的从机准备就绪后，任务分配器继续按照原有的设计策略分配任务。主从架构与主备架构相比，

优缺点有：优点：主从架构的从机也执行任务，发挥了从机的硬件性能。缺点：主从架构需要将任务分类，任务分配器会复杂一些。

高可用计算的集群方案根据集群中服务器节点角色的不同，可以分为两类：一类是对称集群，即集群中每个服务器的角色都是一样的，都可以执行所有任务；另一类是非对称集群，集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，例如最常见的 Master-Slave 角色。

业务高可用的保障：异地多活架构

地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方；多活就是指不同地理位置上的系统都能够提供业务服务。判断一个系统是否符合异地多活，

需要满足两个标准：正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务。

异地多活架构代价很高，具体表现为：系统复杂度会发生质的变化，需要设计复杂的异地多活架构。成本会上升，毕竟要多在一个或者多个机房搭建独立的一套业务系统。

同城异区关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计，无须额外考虑。

跨城异地关键在于数据不一致的情况下，业务不受影响或者影响很小，这从逻辑的角度上来说其实是矛盾的，架构设计的主要目的就是为了解决这个矛盾。

跨国异地主要是面向不同地区用户提供业务，或者提供只读业务，对架构设计要求不高。

异地多活架构4 大技巧：1：保证核心业务的异地多活；优先实现核心业务的异地多活架构；2：保证核心数据最终一致性3：采用多种手段同步数据；4：只保证绝大部分用户的异地多活

同步数据的几种方式：消息队列方式；二次读取方式；存储系统同步方式；重新生成数据方式

异地多活设计的理念可以总结为一句话：采用多种手段，保证绝大部分用户的核心业务异地多活！

跨城异地多活架构设计的 4 个步骤

第 1 步：业务分级：分级标准有下面几种：访问量大的业务，核心业务，产生大量收入的业务

第 2 步：数据分类：常见的数据特征分析维度有：数据量，唯一性，实时性，可丢失性，可恢复性

第 3 步：数据同步：数据同步方案有：存储系统同步，消息队列同步，重复生成，

第 4 步：异常处理：异常处理主要有以下几个目的：

问题发生时，避免少量数据异常导致整体业务不可用。

问题恢复后，将异常的数据进行修正。

对用户进行安抚，弥补用户损失。

常见的异常处理措施有这几类：1. 多通道同步，2. 同步和访问结合3. 日志记录4. 用户补偿

如何应对接口级的故障？

接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。例如，业务响应缓慢、大量访问超时、大量访问出现异常（给用户弹出提示“无法连接数据库”），这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。例如，最常见的数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库、要么超时，最终用户看到的现象就是访问很慢，一会访问抛出异常，一会访问又是正常结果

导致接口级故障的原因：内部原因程序 bug 导致死循环。外部原因黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户。解决接口级故障的核心思想和异地多活基本类似：优先保证核心业务和优先保证绝大部分用户。

降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况

降级：常见的实现降级的方式有：系统后门降级；独立降级系统

熔断：熔断机制实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。熔断机制实现的另外一个关键是阈值的设计，例如 1 分钟内 30% 的请求响应时间超过 1 秒就熔断，这个策略中的“1 分钟”“30%”“1 秒”都对最终的熔断效果有影响。实践中一般都是先根据分析确定阈值，然后上线观察效果，再进行调优

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。

常见的限流方式可以分为两类：基于请求限流和基于资源限流

基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量

排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待一段时间，全世界最有名的排队当属 12306 网站排队了。排队虽然没有直接拒绝用户，但用户等了很长时间后进入系统，体验并不一定比限流好。