【架构师之路】理解 CAP 理论：分布式系统中的权衡与选择 | 常用组件中的CP和AP

CAP定理是分布式系统设计中的一个基本定理，它指出在一个分布式计算系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）三者不可同时实现，最多只能同时满足其中的两个。

一致性（Consistency）

所有节点在同一时间的数据视图是一致的。即，如果系统接受了更新操作，在之后的所有访问操作中都能获取到最新的数据。

可用性（Availability）

系统保证每个非故障节点在有限时间内返回合理的响应，即系统对于用户的每一个操作请求总是能够在有限时间内返回结果。

分区容忍性（Partition Tolerance）

系统在遇到网络分区故障时仍然能够继续运行。即，系统能够在网络发生故障或分区时继续对外提供服务。

根据CAP定理，在分布式系统设计中，当网络出现分区时，系统需要在一致性和可用性之间做出权衡。分布式系统往往会选择牺牲一致性以保证可用性和分区容忍性，或者牺牲可用性以保证一致性和分区容忍性。

CAP定理的实际含义是：在分布式系统中，由于网络分区的存在，系统无法同时保证一致性、可用性和分区容忍性，因此在设计分布式系统时需要根据具体需求和场景做出权衡。

CAP 三要素之间的冲突的关系

在分布式系统中，由于网络分区的存在，系统无法同时保证一致性、可用性和分区容忍性，因此在设计分布式系统时需要根据具体需求和场景做出权衡。

CA without P

如果放弃分区容忍性（CA without P）：强调 单节点， 单副本，或者只有一个正本，没有副本。简单说，CA 将所有数据都放在一个分布式节点上，这同时放弃了系统的可扩展性， 不属于 分布式系统范围了。

意味着我们将假设节点之间通信永远是可靠的。永远可靠的通信在分布式系统中必定不成立的，这不是你想不想的问题，而是只要用到网络来共享数据，分区现象就会始终存在。在现实中，最容易找到放弃分区容忍性的例子便是传统的关系数据库集群，这样的集群虽然依然采用由网络连接的多个节点来协同工作，但数据却不是通过网络来实现共享的。以 Oracle 的 RAC 集群为例，它的每一个节点均有自己独立的 SGA、重做日志、回滚日志等部件，但各个节点是通过共享存储中的同一份数据文件和控制文件来获取数据的，通过共享磁盘的方式来避免出现网络分区。因而 Oracle RAC 虽然也是由多个实例组成的数据库，但它并不能称作是分布式数据库。

CP without A

强调副本之间的 强一致性， 意味着低性能。一旦系统遇到故障时，受影响的服务器需要等待一段时间，在恢复期间无法对外提供正常的服务。

意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制地延长，此时，问题相当于退化到前面“全局事务”中讨论的一个系统使用多个数据源的场景之中，我们可以通过 2PC/3PC 等手段，同时获得分区容忍性和一致性。在现实中，选择放弃可用性的 CP 系统情况一般用于对数据质量要求很高的场合中，除了 DTP 模型的分布式数据库事务外，著名的 HBase 也是属于 CP 系统，以 HBase 集群为例，假如某个 RegionServer 宕机了，这个 RegionServer 持有的所有键值范围都将离线，直到数据恢复过程完成为止，这个过程要消耗的时间是无法预先估计的。

AP without C

强调副本之间的 高性能， 意味着 弱一致性。这里的放弃一致性是指放弃数据强一致性，而保留数据的最终一致性。系统无法实时保持数据的一致，但承诺在一个限定的时间窗口内，数据最终能够达到一致的状态。

意味着我们将假设一旦发生分区，