mysql数据库cap理论_CAP理论总结

C 代表 Consistency，一致性，是指所有节点在同一时刻的数据 是相同的，即更新操作执行结束并响应用户完成后，所有节点存储的数据会保持相同。

A 代表 Availability，可用性，是指系统提供的服务一直处于可用状态， 对于用户的请求可即时响应。

P 代表 Partition Tolerance，分区容错性，是指在分布式系统遇到 网络分区的情况下，仍然可以响应用户的请求。网络分区是指因为网络故障导致网络不连 通，不同节点分布在不同的子网络中，各个子网络内网络正常。

在电商系统中，假设 C 与 A 和 B 的网络都不通了，A 和 B 是相通的。也就是说，形成了两 个分区{A, B}和{C}，在这种情况下，系统仍能响应用户请求。

CAP 理论指的就是，在分布式系统中 C、A、P 这三个特征不能同时满足，只能满足其中两 个。

网络中有两台服务器 Server1 和 Server2，分别部署了数据库 DB1 和 DB2， 这两台机器组成一个服务集群，DB1 和 DB2 两个数据库中的数据要保持一致，共同为用户 提供服务。用户 User1 可以向 Server1 发起查询数据的请求，用户 User2 可以向服务器 Server2 发起查询数据的请求，它们共同组成了一个分布式系统。

在满足一致性 C 的情况下，Server1 和 Server2 中的数据库始终保持一致，即 DB1 和 DB2 内容要始终保持相同； 在满足可用性 A 的情况下，用户无论访问 Server1 还是 Server2，都会得到即时响应； 在满足分区容错性 P 的情况下，Server1 和 Server2 之间即使出现网络故障也不会影响 Server1 和 Server2 分别处理用户的请求。

当用户发起请求时，收到请求的服务器会及时响应，并将用户更新的数据同步到另一台服务 器，保证数据一致性。

在实际场景中，网络环境不 可能百分之百不出故障，比如网络拥塞、网卡故障等，会导致网络故障或不通，从而导致节 点之间无法通信，或者集群中节点被划分为多个分区，分区中的节点之间可通信，分区间不 可通信。 这种由网络故障导致的集群分区情况，通常被称为“网络分区”。 在分布式系统中，网络分区不可避免，因此分区容错性 P 必须满足。

假设在满足P的情况下，Server1 和 Server2 之间网络出现故障，User1 向 Server1 发送请求，将数据库 DB1 中的数据 a 由 1 修改为 2，而 Server2 由于与 Server1 无法连接导致数据无法同步， 所以 DB2 中 a 依旧是 1。这时，User2 向 Server2 发送读取数据 a 的请求时，Server2 无法给用户返回最新数据，

处理方式有如下两种。 第一种处理方式是，保证一致性 C，牺牲可用性 A：Server2 选择让 User2 的请求阻塞， 一直等到网络恢复正常，Server1 被修改的数据同步更新到 Server2 之后，即 DB2 中数据 a 修改成最新值 2 后，再给用户 User2 响应。第二种处理方式是，保证可用性 A，牺牲一致性 C：Server2 选择将旧的数据 a=1 返回给 用户，等到网络恢复，再进行数据同步。

比如对于涉及钱的交易时，数据的一致性至关重要，因此保 CP 弃 A 应该是最佳选择。而对于其他场景，大多数情况下的做法是选择 AP 而牺牲 C，因为很多情况下不需要太强的 一致性(数据始终保持一致)，只要满足最终一致性即可。 最终一致性指的是，不要求集群中节点数据每时每刻保持一致，在可接受的时间内最终能达 到一致就可以了。

分布式事务中基于分布式 消息的最终一致性方案对事务的处理，就是选择 AP 而牺牲 C 的例子。 这个方案中，在应用节点之间引入了消息中间件，不同节点之间通过消息中间件进行交互， 比如主应用节点要执行修改数据的事务，只需要将信息推送到消息中间件，即可执行本地的 事务，而不需要备应用节点同意修改数据才能真正执行本地事务，备应用节点可以从消息中 间件获取数据。

在分布式系统中，现在的网络基础设施无法做到始终保持稳定，网络分区(网络不连通)难 以避免。牺牲分区容错性 P，就相当于放弃使用分布式系统。既然分布式系统不能采用这种策略，那单点系统毫无疑问就需要满足 CA 特性了。比如关系 型数据库 DBMS(比如 MySQL、Oracle)部署在单台机器上，因为不存在网络通信问 题，所以保证 CA 就可以了。

如果一个分布式场景需要很强的数据一致性，或者该场景可以容忍系统长时间无响应的情况 下，保 CP 弃 A 这个策略就比较适合。 一个保证 CP 而舍弃 A 的分布式系统，一旦发生网络分区会导致数据无法同步情况，就要 牺牲系统的可用性，降低用户体验，直到节点数据达到一致后再响应用户。

保证 CP 的系统有很多，典型的有 Redis、HBase、ZooKeeper 等。

ZooKeeper 集群包含多个节点(Server)，这些节点会通过分布式选举算法选出一个 Leader 节点。在 ZooKeeper 中选举 Leader 节点采用的是 ZAB 算法。

在 ZooKeeper 集群中，Leader 节点之外的节点被称为 Follower 节点，Leader 节点会专 门负责处理用户的写请求： 具体示意图如下所示： 当用户向节点发送写请求时，如果请求的节点刚好是 Leader，那就直接处理该请求；如果请求的是 Follower 节点，那该节点会将请求转给 Leader，然后 Leader 会先向所 有的 Follower 发出一个 Proposal，等超过一半的节点同意后，Leader 才会提交这次写 操作，从而保证了数据的强一致性。

比如当出现网络分区时，如果其中一个分区的节点数大于集群总节点数的一半，那么这个分区可 以再选出一个 Leader，仍然对用户提供服务，但在选出 Leader 之前，不能正常为用户提 供服务；如果形成的分区中，没有一个分区的节点数大于集群总节点数的一半，那么系统不 能正常为用户提供服务，必须待网络恢复后，才能正常提供服务。

这种设计方式保证了分区容错性，但牺牲了一定的系统可用性。

如果一个分布式场景需要很高的可用性，或者说在网络状况不太好的情况下，该场景允许数 据暂时不一致，那这种情况下就可以牺牲一定的一致性了。 网络分区出现后，各个节点之间数据无法马上同步，为了保证高可用，分布式系统需要即刻 响应用户的请求。但，此时可能某些节点还没有拿到最新数据，只能将本地旧的数据返回给 用户，从而导致数据不一致的情况。 适合保证 AP 放弃 C 的场景有很多。比如，很多查询网站、电商系统中的商品查询等，用 户体验非常重要，所以大多会保证系统的可用性，而牺牲一定的数据一致性。

采用保 AP 弃 C 的系统也有很多，比如 Eureka、Cassandra。

CAP 和 ACID 的“C”“A”是一样的吗？

CAP 中的 C 强调的是数据的一致性，也就是集群中节点之间通过复制技术保证每个节点 上的数据在同一时刻是相同的。 ACID 中的 C 强调的是事务执行前后，数据的完整性保持一致或满足完整性约束。也就 是不管在什么时候，不管并发事务有多少，事务在分布式系统中的状态始终保持一致。

CAP 中的 A 指的是可用性(Availability)，也就是系统提供的服务一直处于可用状态， 即对于用户的请求可即时响应。 ACID 中的 A 指的是原子性(Atomicity)，强调的是事务要么执行成功，要么执行失败。