架构师训练营第六周作业

• 请简述 CAP 原理。

CAP 定理

CAP 定理是分布式系统设计中最基础, 也是最为关键的理论。它指出，分布式数据存储不可能同时满足以下三个条件。

• 一致性 (Consistency): 每次读取要么获取最近写入的数据，要么获得一个错误。

• 可用性 (Availability): 每次请求都能获得一个 (非错误) 响应, 但不保证返回的是最新写入的数据。

• 分区容忍性 (Partition tolerance): 尽管任意数量的消息被节点间的网络丢失 (或延迟), 系统仍继续运行。

CAP 定理表明, 在存在网络分区的情况下, 一致性和可用性必须二选一。

分布式系统的三个指标



CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P： 如果不要求 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库 RDBMS：Oracle、MySQL 就是 CA。

CP without A： 如果不要求 A（可用），相当于每个请求都需要在服务器之间保持强一致，而 P（分区）会导致同步时间无限延长 (也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C： 要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

BASE 理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

软状态

和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID 特性与 BASE 理论往往又会结合在一起使用。