CAP理论中能否保证CA，而不保证P？

HaHa

CAP理论认为我们最多只能保证其中两个。我想了很久，如果只保证CA，不保证P，是否有意义？就是说，如果出现脑裂，我可以保证数据一致性，系统还能用，但不保证分区两边的数据是否对得上。明显不保证分区容错，也就不可能保证数据的一致性。所以这个方案可不可以说不行？

原文地址：https://www.zhihu.com/question/267019831

清风寡欲

结合java面试19讲的内容，下面我们聊一下分布式事务：
八，两阶段提交协议

分布式事务是指会涉及到操作多个数据库的事务,在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。
二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
1. 准备阶段
事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交，到达一种“万事俱备，只欠东风”的状态。
2. 提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
3. 缺点
同步阻塞问题
1、执行过程中，所有参与节点都是事务阻塞型的。
单点故障
2、由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。
数据不一致（脑裂问题）
3、在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，导致只有一部分参与者接受到了commit 请求。于是整个分布式系统便出现了数据部一致性的现象(脑裂现象)
二阶段无法解决的问题（数据状态不确定）
4、协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
九. 三阶段提交协议

三阶段提交（ Three-phase commit ），也叫三阶段提交协议（ Three-phase commitprotocol），是二阶段提交（2PC）的改进版本。与两阶段提交不同的是，三阶段提交有两个改动点。
1、引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说，除了引入超时机制之外，3PC 把 2PC 的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。
1. CanCommit 阶段
协调者向参与者发送 commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。
2. PreCommit 阶段
协调者根据参与者的反应情况来决定是否可以继续进行，有以下两种可能。假如协调者从所有的参与者获得的反馈都是 Yes 响应，那么就会执行事务的预执行假如有任何一个参与者向协调者发送了 No 响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
3. doCommit 阶段
该阶段进行真正的事务提交，主要包含 1.协调这发送提交请求 2.参与者提交事务 3.参与者响应反馈（事务提交完之后，向协调者发送 Ack 响应。）4.协调者确定完成事务。
十，柔性事务

1. 柔性事务
在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于 CAP 理论以及 BASE 理论，有人就提出了 柔性事务 的概念。CAP（一致性、可用性、分区容忍性）理论大家都理解很多次了，这里不再叙述。说一下 BASE 理论，它是在 CAP 理论的基础之上的延伸。包括 基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。通常所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。
两阶段型
1、就是分布式事务两阶段提交，对应技术上的 XA、JTA/JTS。这是分布式环境下事务处理的典型模式。
补偿型
2、TCC 型事务（Try/Confirm/Cancel）可以归为补偿型。
WS-BusinessActivity 提供了一种基于补偿的 long-running 的事务处理模型。服务器 A 发起事务，服务器 B 参与事务，服务器 A 的事务如果执行顺利，那么事务 A 就先行提交，如果事务 B 也执行顺利，则事务 B 也提交，整个事务就算完成。但是如果事务 B 执行失败，事务 B 本身回滚，这时事务 A 已经被提交，所以需要执行一个补偿操作，将已经提交的事务 A 执行的操作作反操作，恢复到未执行前事务 A 的状态。这样的 SAGA 事务模型，是牺牲了一定的隔离性和一致性的，但是提高了 long-running 事务的可用性。




异步确保型
3、通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响




最大努力通知型（多次尝试）
4、这是分布式事务中要求最低的一种, 也可以通过消息中间件实现, 与前面异步确保型操作不同的一点是, 在消息由 MQ Server 投递到消费者之后, 允许在达到最大重试次数之后正常结束事务。
十一. CAP

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性（C）：
1. 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：
2. 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：
3. 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

检验医师

当然能了，传统数据库都是假设不保证P的，因为传统数据库都是假设网络不存在问题，这也就是为什么two phase commit在传统数据库被广泛使用了。然而这种假设成立的前提是数据库仅跑在单机上或者很小规模的集群上，网络故障基本不会发生。然而在大规模集群或者geo database上这一假设就不成立了，谁知道网络会什么时候挂呢？在这种情况下仅仅用2PC就靠不住了，毕竟2PC根本handle不了node failure，node failure之后只能手动重启。
关于CAP这个问题我觉得不要钻牛角尖，一个容易陷入的误区就是认为只能build一个CA或者AP或者CP数据库（所谓三者取其二）。CAP被提出其实核心是让developer要时刻把node failure这种可能性考虑在系统设计之中，因而需要设计一些consensus protocol（比如paxos，raft）来保证这种情况下的一致性。实际上node failure也可以被看成网络latency无限大，如何让系统handle这种情况是需要仔细设计的。可以参考一下Eric Brewer的一篇文章“CAP Twelve Years Later: How the Rules Have Changed“
https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2012/0512/T_CO2_CAP12YearsLater.pdf

感恩由您

注意不要陷入误区，不保证P在工程上可以是当出现分区时，拒绝（部分）分区提供服务。事实上大部分依赖Quorum决策（选主）的工程系统，就是舍弃了P。

检验医师

只保证ac就是一个单体应用，根本不是分布式。意义当然有，在分布式出现之前都是这么搭系统。倘若这个系统的节点之一挂了，不会发生脑裂而是整个系统直接宕掉。