CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

CAP原则
百度百科这样定义：

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

我自己的理解是：
* 一致性（C）：所有的数据要保持一致。需要保证数据同步到其他的机器。
* 可用性（A）：用户任何时刻访问服务器数据，都能够保证在一定时间内给出响应。
* 分区容错性（P）：集群的服务器中，即使有一个节点挂了，也不影响其他节点的使用。当然机器数量越多，在相同条件下，容错性越高。

满足C和A，不能满足P
假设不考虑分区（P）的情况下，只有一个分区（副本），副本的一致性自不必说，自然是一致的；可用性方面，一个节点的写入不需要同步到其他节点，可以高效完成。如果增加多个分区（提高分区容错性），数据的写入需要同步到多个节点（强一致性，所有节点同步成功后再返回用户），增加了同步时间和同步失败的可能性，降低了可用性；如果采用弱一致性，即写入操作在主节点成功后即返回用户结果，再通过异步方式同步到多个分区，那么会增加同步失败和数据丢失的几率，降低了一致性。
满足C和P，不能满足A
假设不考虑可用性（A）的情况下，多个分区之间可以采用强一致性的机制，保证数据的高度一致性（要么都成功要么都失败）。比如某个分区出现了故障或者分隔，分区没有了响应，由于放弃了可用性，所以可以无限等待并不断重试直到网络恢复，分区可用后将副本数据同步到所有节点。
满足A和P，不能满足C
假设不考虑一致性（C)的情况下，多个分区和副本可以提供高可用性。分区越多，用户越能就近访问，提供响应速度；放弃了一致性后，副本的写入操作可以写入主节点成功后即可返回成功，获得搞可用性，然后通过异步的方式将副本同步到多个分区节点上。

数据库满足了CA；区块链满足了CP。
注重用户体验，选用AP；注重数据准确、安全，选用CP。