CAP 定理的理解

一、CAP起源

2000年PODC大会上，大牛Brewer提出的CAP猜想：设计一个大规模可伸缩的网络服务时，会遇到三个特性：一致性（Consistency）、可用性（Availability）、分区容错（partition-tolerance）都需要的情况，然后这是不可能都实现的。之后再2003年，MIT的Gibert和Lynch就正式的证明了这三个特性确实是不可以兼得的，该理论是NoSQL数据库管理系统构建的基础



二、CAP定义

2.1 定义

它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistency）：数据在多个副本之间能够保持一致的特性（All clients always have the same view of the data）

• 可用性（Availability）：系统提供的服务必须一致处于可用的状态，每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据（Each client can always read and write）

• 分区容错性（Partition tolerance）： 以实际效果而言，分区相当于对通信的时限要求，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分出分区两侧，允许至少一个节点更新状态会导致数据不一致，即丧失了C性质，如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质，除非这两个节点互相通信，才能既保证C又保证A，这又会导致丧失P性质。



2.2 CAP的选择

选择C和A，放弃P：如果想避免分区容错性问题的发生，一种做法就是将所有的数据（与事务相关的）都放在一台机器上，虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果，当然这个选择会严重的影响系统的扩展性；

选择C和P，放弃A：一旦遇到分区容错故障，那么受到影响的服务需要等待一段时间。因此在等待期间，系统对外部来说是不可用的，无法对外提供服务

选择A和P，放弃C：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性；

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的，所以我们只能在一致性和可用性之间进行权衡；