架构 0 期 -week6- 命题作业

下面两题，至少选做一题

• 请简述 CAP 原理。

• 针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）

CAP

在理论计算机科学中，CAP 定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：[1][2]

• 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）

• 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）

• 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择[3]。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点可以互相通信，才能既保证 C 又保证 A，这又会导致丧失 P 性质。

以上直接 copy 自维基百科，我想这不是想要的作业。

说说我对 CAP 的理解与感受。

首先我们讨论分布式系统，那天生的 P 是一定无法满足的。也就是在 C、A 之间做偏向于权衡。

但是，往往 C 与 A 也并非如想象中那么非此即彼，一切还是要看业务场景。举个栗子。

我关注了极客时间公众号。

首先，最核心的是要把我关注极客时间公众号这个关系落库，然后我会收到关注动作的反馈，界面上显示“你已成功关注极客时间 xxxx”，这是一个同步动作。

其次，关注这个动作还可能有的功能是在公众号运营后台有一个推送，“陈俊关注了你”，这是推送服务负责的。

从逻辑上来讲，这是一个关注的业务流程，应该保证一致性，即保存关注关系和推送公众号运营后台需要事务。但是我们都知道事务有更大的性能损耗，更复杂的计算需求，也就是相比没事务可用性更低。所以这样的做法是在 C 与 A 之间做出了偏向于 C 一致性的选择，即推送服务因为分区缘故，关注功能可能返回错误，降低可用性。

但我们通常认为运营后台的消息推送并不是一个必须同步成功的功能，而用户关注的反馈更加重要。即，只要关注关系落库成功，就应该告诉用户你关注成功了，提高用户体验。所以做出了一些改进。

一般利用 mq 解耦，关注关系落库成功后，即发出关注成功 mq 消息，然后就返回给用户他关注成功了。而推送功能在这个 mq 消息的 consumer 去做，即使极小可能的推送失败，也是可以接受的。这样就提高了 A 可用性，但是接受预定 C 一致性的损失，因为关注功能并没有同步到推送是否成功。

以上。

Doris 临时失效时序图

待补充