CAP原理
在一个分布式系统（指系统中的节点互相连接并共享数据）中，当涉及读写操作时，只能保证一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition Tolerance)三者中的两个，另外一个必须被牺牲。
一致性：CAP中的C和ACID 中的C不是一个含义，ACID 中的C是指数据库中的数据满足一定的约束条件。而CAP中的C是指线性一致性，即：客户端向系统写入什么，那么读出来的也会是什么。也就是要保证客户端读取到的数据一定是上次写入的最新数据。
可用性：指系统中的部分节点出现故障后，系统能否还能对外提供完全可用的服务；
分区容错性：指是否允许系统中的节点之间无法通信，也就是无法互相连接；
适用场景
那么什么样的分布式系统是节点之间互联并共享数据呢？
典型的场景就是数据库的主从集群，一个数据库集群有一个主，多个从，主从之间会进行数据复制。所以适用于CAP原理。
那么如果我现在是一个Redis的集群，集群中每台机器存储不同的数据，集群中每台机器不需要复制和传递数据，那么就不属于CAP原理的讨论范围。同理，如果是A,B两个不同的业务系统，比如招行账号A给工行账号B转账100元，由于招行和工行是两个不同的业务系统，业务上隔离，且他们之间也没有共享的数据，从而也不属于CAP原理的讨论范围。
场景方案选择
传统数据库主从集群：如果当前是一个现在是一个主从复制的数据库集群，同一条数据会在主从数据库上都存储，那么当存在主从数据库之间网络断开时，我们确实只能要么选择A放弃C，要么选择C放弃A。选择A放弃C，就是客户端读取到的可能不是最新的数据，但是系统持续可用；选择C放弃A，就是让系统服务不可用，客户端自然就不会认为数据不一致了。
分布式数据库，如阿里的OceanBase，这种数据库也是一个主从的集群，但是主从节点往往使用Paxos/Raft等副本一致性协议，做到整个数据库系统，在部分节点发生故障时，也能在很短的时间内自动重新选主，选出一个新的主从集群的数据库系统。在重新选主的过程中，系统不可用，相当于放弃了A，而一旦选出新的主之后，系统又继续可用，且数据对外是线性一致的。相比传统的数据库主从集群，分布式数据库由于可以在遇到网络分区导致数据库主从节点之间无法互联时，可以快速选出新的主，然后快速恢复，所以架构设计上和用户体验上，要好很多。但是系统设计的复杂度也非常高。
分布式事务
通过上面的分析，我们知道CAP中的数据一致性，本质上是为了维护同一个数据的不同副本之间的一致性。而更多的时候，我们要解决的是不同业务系统之间的数据一致性，即数据之间总是应该满足规定的业务规则。典型的场景比如有跨行转账、订单和减库存。这种场景，由于没有数据共享的特征，所以不适用于CAP。比如A银行的账户给B银行的账户转账100元，那么转账前后，两个账户的钱加起来应该不变。也就是A扣款了，B就必须加款。那么这种场景如何解决呢？一般的做法是采用分布式事务，常见的分布式事务的解决方案有：2PC\3PC、TCC、基于分布式MQ+本地消息、分布式MQ事务消息、Sagas。