CAP原则又称作CAP定理，是Brewer教授提出的，指的是在一个分布式系统中，三个要素最多只能同时实现两点，不可能三者兼顾。分布式系统提供的是最终一致性，而不是强一致性。分布式锁和分布式事务都是为了保证数据的最终一致性。
**一致性©：**Consistency，在分布式系统中的所有数据备份，在同一时刻是否有同样的值（等同于所有节点访问同一份最新的数据副本）。
通过某个节点的写操作结果对后面其他节点的读操作可见
- 强一致性:如果更新数据后，并发访问情况下可立即感知该更新。
- 弱一致性:如果允许之后的部分或者全部感知不到该更新。
- 最终一致性:若在之后的一段时间（通常该时间不固定）后，一定可以感知该更新。
**可用性(A)：**Availability，在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）。
- 任何一个没有发生故障的节点必须在有限的时间内返回合理的结果。
**分区容错性(P)：**Partition tolerance，在出现网络分区（如断网）的情况下，分离的系统也能正常运行。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
- 部分节点宕机或者无法与其他节点通信时，各分区还可以保持分布式系统的功能。
一般分区容忍性都要求有保障，因此很多时候是在可用性与一致性之间做权衡。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP：如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备。但是如果系统发生了网络分区状况或宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
因此，在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用memcached之类的NOSQL作为实现手段。虽然memcached也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台memcached服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式memcached之间进行数据的同步和持久化，但是实现难度非常大。
其他：
分区——
数据散布在不连通的区域中,就叫分区。提高分区容错性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里，容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，即多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。