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。