第六周作业

CAP原理

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

• 一致性：CAP中的C和ACID 中的C不是一个含义，ACID 中的C是指数据库中的数据满足一定的约束条件。而CAP中的C是指线性一致性，即：客户端向系统写入什么，那么读出来的也会是什么。也就是要保证客户端读取到的数据一定是上次写入的最新数据。

• 可用性：指系统中的部分节点出现故障后，系统能否还能对外提供完全可用的服务；

• 分区容错性：指是否允许系统中的节点之间无法通信，也就是无法互相连接；



典型的场景就是数据库的主从集群，一个数据库集群有一个主，多个从，主从之间会进行数据复制。所以适用于CAP原理。

那么如果我现在是一个Redis的集群，集群中每台机器存储不同的数据，集群中每台机器不需要复制和传递数据，那么就不属于CAP原理的讨论范围。同理，如果是A,B两个不同的业务系统，比如招行账号A给工行账号B转账100元，由于招行和工行是两个不同的业务系统，业务上隔离，且他们之间也没有共享的数据，从而也不属于CAP原理的讨论范围。



CAP定理告诉我们CAP这三种特性不能同时完全满足,因此存在以下三种取舍情况：　

　　1.选择CA，放弃P

　　通常是由一台非常强大的计算机对外提供服务来保证A（高可用性），所有的数据操作都在同一台机器上。在上面提到的银行账户转账例子中，在数据库层面上通过本地事务来轻松满足C（（强）一致性）。试想如果此时想要拥有P，即转账双方位于不同分区，那么一旦被转账方出现故障，要么耗费时间等待其重新开始服务（放弃A）；或者暂时仅仅处理转账方的业务，等待后续的一致性补偿操作（放弃C）。

　　该方案的缺点：由于目前科学技术上的限制，无法横向扩容的系统是无法应付海量请求，大并发的场景的，同时也容易导致单点故障出现，因此这里的A（高可用性）实际上是大打折扣的。

　　2.选择CP，放弃A。

　　意味着系统在提供服务时，一旦出现分区故障，为了确保数据的强一致性，所涉及到的服务全部都会停止响应，因此A（高可用性）也就不复存在啦。暂时还没有想到什么场景下会采取这种方案。

　　该方案的缺点：低可用性本身就是系统的一大缺点。

　　3.选择AP，放弃C。

这种架构可以说是如今互联网时代最流行的架构。通过分布式和集群进行横向的系统性能拓展，尽可能的舍弃对数据强一致性的需求，同时在遇到不可避免的分布式事务场景时

　　该方案的缺点：不适合对数据一致性C（（强）一致性）有极高要求的场景，以及不追求A（高可用性）的场景（分区总是会带来额外的麻烦）。

　　其实，选择AP而放弃C的设计理念并不仅仅适用于整个系统的整体架构，例如在系统内部，数据库集群（可以理解为一个子系统）主从分离的同步延迟造成从库数据与主库数据出现数据暂时不一致的情况等等。

　　除此之外，CAP中的三个元素也并不是完全的互斥，例如选择AP，其实也不是彻底的放弃了C（一致性），而是进行了一定程度的让步，同时C（一致性）也能细分为读一致性，写一致性等。因此不能机粗暴的将CAP理论理解为完全互斥，三选二，而是在这三个维度上面进行不同程度的取舍。CAP理论其实是告诉人们天下没有免费的午餐，也不存在完美无缺的系统设计，需要反复的斟酌，权衡，才能设计出合理的，符合需求的系统架构



CAP中的数据一致性，本质上是为了维护同一个数据的不同副本之间的一致性。而更多的时候，我们要解决的是不同业务系统之间的数据一致性，即数据之间总是应该满足规定的业务规则。典型的场景比如有跨行转账、订单和减库存。这种场景，由于没有数据共享的特征，所以不适用于CAP。比如A银行的账户给B银行的账户转账100元，那么转账前后，两个账户的钱加起来应该不变。也就是A扣款了，B就必须加款。那么这种场景如何解决呢？一般的做法是采用分布式事务，常见的分布式事务的解决方案有：2PC\3PC、TCC、基于分布式MQ+本地消息、分布式MQ事务消息、Sagas