CAP 原理简述

CAP 原理说的是在分布式系统中，有三个指标。分别是 Consistency（一致性）Availability （可用性）Partition tolerance (分区容错性)，这三个指标不可能同时做到。为什么说这三个指标不可能同时做到呢？

我们先来看一下这三个指标的分别说的是什么。

Partition tolerance（分区容错性）：指的是因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的。

在分布式系统中，机器分布在各个不同的地方，由网络进行连接。由于各地的网络情况不同，网络的延迟甚至是中断是不可避免的。分区容错性指的就是服务器之间通信异常的情况。

举个例子，有两台数据库服务器，做了读写分离。一台主服务器在杭州，负责所有的写操作；一台从服务器在深圳，负责所有的读操作，两台服务器之间进行主从复制。两台服务器之间很有可能出现网络抖动，异常的情况，从而导致主从复制失败。这就是所谓的“分区容错”。

在分布式系统中，网络情况是无法完全保证的，即 CAP 中的 P 总是存在的。

Consistency（一致性）：每次读取的数据都应该是最近写入的数据或者返回一个错误, 而不是过期数据，也就是说，数据是一致的。

Availability（可用性）：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的,也就是说系统需要一直都是可用正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。

拿上面的例子来说，如果主从服务器之间网络没有问题，主从复制正常，那么数据一致性，可用性是有保障的。但是如果网络出现了问题，主从复制异常，那么就会有数据不同步的情况。这种情况下有两个选择

，一个是保证可用性，允许出现数据不一致的情况，依然在主数据库写，从数据库读。一个是保证一致性，关闭主数据库，禁止写操作，确保主从数据一致，等服务器之间网络恢复了，再开放写操作。

也就是说，在服务器之间的网络出现异常的情况下，一致性和可用性是不可能同时满足的，必须要放弃一个，来保证另一个。这也正是 CAP 定理所说的，在分布式系统中，P 总是存在的。在 P 发生的前提下，C(一致性)和 A（可用性）不能同时满足。这种情况在做架构设计的时候就要考虑到，要评估对业务的影响，进行权衡决定放弃哪一个。在通常的业务场景下，系统不可用是不能接受的，所以要优先保证可用性，暂时放弃一致性。