架构师训练营第六周 - 作业

简述CAP原理

概念

CAP原理是指对一个分布式系统，不可能同时满足以下三点：

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

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

• 分区耐受性（Partition tolerance）—— 节点间网络通信发生了丢失消息或消息延迟（导致系统各节点不能在时限内达成一致的看法）造成分区，系统仍然可以使用



解释

想象在系统发生分区时，有两个分别处于分区两侧的节点。如果允许其中一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据的一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点能够恢复互相通信，才能同时呈现出 C 和 A。通常架构师无法选择是否要 P（因为在实践当中网络故障或通信延迟总会发生），所以在发生分区时只能在 C 和 A 之间作出选择。



传统的关系数据库系统通常以提供 ACID 特性为主导思想，但是在互联网应用的高并发和大数据量场景下，单机处理的上限已无法满足要求，多服务节点的分布式系统成为唯一可行的方案，这时就要在CAP三者之间进行取舍。



但CAP理论并非严格的“三选二”，非黑即白：

• 首先，分区很少发生，在系统不存在分区的情况下，没理由牺牲 C 或 A

• 其次， C 和 A 之间的取舍可以在系统内以不同的粒度作出，每次取舍的决策也可能因为牵涉的数据或用户不同而有所不同（不必僵化地要求对整个系统只存在一种恒定不变的取舍方式）

• 可用性可分为不同的程度，而不仅仅是 0 和 1；一致性也可以分不同的级别；甚至连分区也可能有不同的含义（例如系统内部的不同部分对于是否存在分区可以有不同的认知）



近年涌现的各种 NoSQL 系统，就是在不同程度上对可用性、一致性进行取舍的方案。这些系统放弃了传统数据库的 ACID，而采用 BASE：

• 基本可用（Basicallly Available）—— 响应时间加长或者部分功能损失

• 软状态（Soft state）—— 系统中的数据存在中间状态，数据副本间同步存在延迟

• 最终一致性（Eventually Consistent）—— 经过一段时间后数据最终能达到一致，但不能实时保证系统数据的强一致性



讨论

一致性的作用范围

对一致性作用范围的划定，可以影响 CAP 的整体效果。例如在一个主分区内内保证一致和可用，但在分区外服务可能不可用。分区期间，独立且能自我保证一致性的节点子集可以继续操作。



放弃严格一致性意味着什么

选择可用性牺牲一致性，意味着在分区结束后最终需要恢复到一致，以满足业务上的不变性约束。需要考虑以下三个点：

• 检测到分区的发生（注意分区可能并非全体节点的一致见解，通信延迟的时限也需要由设计者根据需求而定）

• 明确进入分区模式后，限制某些操作（例如可能违反业务不变性约束的操作）

• 通信恢复后进行分区恢复，达到最终一致的状态，以及补偿在系统分区过程期间可能产生的错误。（例如超卖，视乎具体业务而定）



https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

恢复时解决数据一致性冲突的技术手段

• 时间戳，最后写入胜出

• 节点投票

• 客户端解决

业务设计与CAP

例如电商系统的下单操作，接收到用户的下单请求时，先记录下订单信息，并返回“订单处理中”状态，而不是直接在下单时马上执行扣减库存、扣费等具有外部化特征的事务。系统以用户不易察觉的方式降低了可用性，用户只知道自己下了指令，系统稍后会执行。



依靠审计和补偿，例如透支后收取补偿费用。

总结

在网络正常的时候，分布式系统可以同时保证一致性和可用性。但网络故障总有可能发生（高可靠的网络会帮助减少故障发生的概率，但无法彻底避免），这时无法同时保证一致性和可用性，需要在C和*A*两者之间进行取舍。某些故障组合甚至可能导致同时丢失 C 和 A。



CAP 三个性质是一个度的问题，设计者可以在不同程度的可用性与一致性间作出不同的组合。

参考

Eric Brewer, “CAP Twelve Years Later: How the Rules Have Changed”

Martin Kleppmann, “Designing Data-Intensive Applictaions”