分布式数据存储系统：CAP理论
分布式数据存储系统：CAP理论
- 前言
- 什么是 CAP？
- CAP 选择策略及应用
-
- 保 CA 弃 P
- 保 CP 弃 A
- 保 AP 弃 C
- 对比分析
- 知识扩展：CAP 和 ACID 的“C”“A”是一样的吗？
- 总结
前言
分布式系统处理的关键对象是数据，而数据其实是与用户息息相关的。CAP 理论指导分布式系统的设计，以保证系统的可用性、数据一致性等特征。比如电商系统中， 保证用户可查询商品数据、保证不同地区访问不同服务器查询的数据是一致的等。
什么是 CAP？
假设某电商，在北京、杭州、上海三个城市建立了仓库，同时建立了对应的服务器{A, B, C} 用于存储商品信息。比如，某电吹风在北京仓库有 20 个，在杭州仓库有 10 个，在上海仓库有 30 个。
C 代表 Consistency，一致性，是指所有节点在同一时刻的数据是相同的，即更新操作执行结束并响应用户完成后，所有节点存储的数据会保持相同。
在电商系统中，A、B、C 中存储的该电吹风的数量应该是 20+10+30=60。假设，现在有一个北京用户买走一个电吹风，服务器 A 会更新数据为 60-1=59，与此同时要求 B 和 C 也更新为 59，以保证在同一时刻，无论访问 A、B、C 中的哪个服务器，得到的数据均是 59。
A 代表 Availability，可用性，是指系统提供的服务一直处于可用状态， 对于用户的请求可即时响应。
在电商系统中，用户在任一时刻向 A、B、C 中的任一服务器发出请求时，均可得到即时响应，比如查询商品信息等。
P 代表 Partition Tolerance，分区容错性，是指在分布式系统遇到网络分区的情况下，仍然可以响应用户的请求。网络分区是指因为网络故障导致网络不连通，不同节点分布在不同的子网络中，各个子网络内网络正常。
在电商系统中，假设 C 与 A 和 B 的网络都不通了，A 和 B 是相通的。也就是说，形成了两 个分区{A, B}和{C}，在这种情况下，系统仍能响应用户请求。
一致性、可用性和分区容错性，就是分布式系统的三个特征。
CAP 理论：在分布式系统中 C、A、P 这三个特征不能同时满足，只能满足其中两个，如下图所示：
什么是 CAP 以及 CAP 为什么不能同时满足：
如下图所示，网络中有两台服务器 Server1 和 Server2，分别部署了数据库 DB1 和 DB2， 这两台机器组成一个服务集群，DB1 和 DB2 两个数据库中的数据要保持一致，共同为用户提供服务。用户 User1 可以向 Server1 发起查询数据的请求，用户 User2 可以向服务器 Server2 发起查询数据的请求，它们共同组成了一个分布式系统。
对这个系统来说，分别满足 C、A 和 P 指的是：
- 在满足一致性 C 的情况下，Server1 和 Server2 中的数据库始终保持一致，即 DB1 和 DB2 内容要始终保持相同；
- 在满足可用性 A 的情况下，用户无论访问 Server1 还是 Server2，都会得到即时响应；
- 在满足分区容错性 P 的情况下，Server1 和 Server2 之间即使出现网络故障也不会影响 Server1 和 Server2 分别处理用户的请求。
当用户发起请求时，收到请求的服务器会及时响应，并将用户更新的数据同步到另一台服务器，保证数据一致性。具体的工作流程，如下所示：
- 用户 User1 向服务器 Server1 发起请求，将数据库 DB1 中的数据 a 由 1 改为 2；
- 系统会进行数据同步，即图中的 S 操作，将 Server1 中 DB1 的修改同步到服务器 Server2 中，使得 DB2 中的数据 a 也被修改为 2；
- 当 User2 向 Server2 发起读取数据 a 的请求时，会得到 a 最新的数据值 2。
这其实是在网络环境稳定、系统无故障的情况下的工作流程。但在实际场景中，网络环境不可能百分之百不出故障，比如网络拥塞、网卡故障等，会导致网络故障或不通，从而导致节点之间无法通信，或者集群中节点被划分为多个分区，分区中的节点之间可通信，分区间不 可通信。 这种由网络故障导致的集群分区情况，通常被称为“网络分区”。
在分布式系统中，网络分区不可避免，因此分区容错性 P 必须满足。在满足分区容错性 P 的情况下，一致性 C 和可用性 A 是否可以同时满足。
假设，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 返回给用户，等到网络恢复，再进行数据同步。
除了以上这两种方案，没有其他方案可以选择。可以看出：在满足分区容错性 P 的前提下，一致性 C 和可用性 A 只能选择一个，无法同时满足。
CAP 选择策略及应用
分布式系统无法同时满足 CAP 这三个特性，C、A 和 P，没有谁优谁劣，只是不同的分布式场景适合不同的策略。
比如，对于涉及钱的交易时，数据的一致性至关重要，因此保 CP 弃 A 应该是最佳选择。 2015 年发生的支付宝光纤被挖断的事件，就导致支付宝就出现了不可用的情况。显然，支付宝当时的处理策略就是，保证了 CP 而牺牲了 A。
而对于其他场景，大多数情况下的做法是选择 AP 而牺牲 C，因为很多情况下不需要太强的一致性（数据始终保持一致），只要满足最终一致性即可。
最终一致性：不要求集群中节点数据每时每刻保持一致，在可接受的时间内最终能达到一致就可以了。分布式事务中的基于分布式 消息的最终一致性方案对事务的处理，就是选择 AP 而牺牲 C 的例子。这个方案中，在应用节点之间引入了消息中间件，不同节点之间通过消息中间件进行交互， 比如主应用节点要执行修改数据的事务，只需要将信息推送到消息中间件，即可执行本地的事务，而不需要备应用节点同意修改数据才能真正执行本地事务，备应用节点可以从消息中间件获取数据。
保 CA 弃 P
在分布式系统中，网络基础设施无法做到始终保持稳定，网络分区（网络不连通）难以避免。牺牲分区容错性 P，就相当于放弃使用分布式系统。因此，在分布式系统中，这种策略不需要过多讨论。
既然分布式系统不能采用这种策略，那单点系统毫无疑问就需要满足 CA 特性了。比如关系型数据库 DBMS（比如 MySQL、Oracle）部署在单台机器上，因为不存在网络通信问题，所以保证 CA 就可以了。
保 CP 弃 A
如果一个分布式场景需要很强的数据一致性，或者该场景可以容忍系统长时间无响应的情况下，保 CP 弃 A 这个策略就比较适合。一个保证 CP 而舍弃 A 的分布式系统，一旦发生网络分区会导致数据无法同步情况，就要牺牲系统的可用性，降低用户体验，直到节点数据达到一致后再响应用户。这种策略通常用在涉及金钱交易的分布式场景下，因为它任何时候都不允许出现数据不一致的情况，否则就会给用户造成损失。因此这种场景下必须保证 CP。
保证 CP 的系统有 Redis、HBase、ZooKeeper 等。以 ZooKeeper 为例：
ZooKeeper 集群包含多个节点（Server），这些节点会通过分布式选举算法选出一个 Leader 节点。在 ZooKeeper 中选举 Leader 节点采用的是 ZAB 算法。
在 ZooKeeper 集群中，Leader 节点之外的节点被称为 Follower 节点，Leader 节点会专门负责处理用户的写请求：
- 当用户向节点发送写请求时，如果请求的节点刚好是 Leader，那就直接处理该请求；
- 如果请求的是 Follower 节点，那该节点会将请求转给 Leader，然后 Leader 会先向所有的 Follower 发出一个 Proposal，等超过一半的节点同意后，Leader 才会提交这次写操作，从而保证了数据的强一致性。
具体示意图如下所示：
当出现网络分区时：
- 如果其中一个分区的节点数大于集群总节点数的一半，那么这个分区可以再选出一个 Leader，仍然对用户提供服务，但在选出 Leader 之前，不能正常为用户提供服务；
- 如果形成的分区中，没有一个分区的节点数大于集群总节点数的一半，那么系统不能正常为用户提供服务，必须待网络恢复后，才能正常提供服务。
这种设计方式保证了分区容错性，但牺牲了一定的系统可用性。
保 AP 弃 C
如果一个分布式场景需要很高的可用性，或者说在网络状况不太好的情况下，该场景允许数据暂时不一致，那这种情况下就可以牺牲一定的一致性了。
网络分区出现后，各个节点之间数据无法马上同步，为了保证高可用，分布式系统需要即刻响应用户的请求。但此时可能某些节点还没有拿到最新数据，只能将本地旧的数据返回给用户，从而导致数据不一致的情况。
适合保证 AP 放弃 C 的场景有很多。比如，很多查询网站、电商系统中的商品查询等，用户体验非常重要，所以大多会保证系统的可用性，而牺牲一定的数据一致性。
以电商购物系统为例，如下图所示，某电吹风在北京仓库有 20 个，在杭州仓库有 10 个， 在上海仓库有 30 个。初始时，北京、杭州、上海分别建立的服务器{A, B, C}存储该电吹风 的数量均为 60 个。
假如，上海的网络出现了问题，与北京和杭州网络均不通，此时北京的用户通过北京服务器 A 下单购买了一个电吹风，电吹风数量减少到 59，并且同步给了杭州服务器 B。现在用户的查询请求如果是提交到服务器 A 和 B，那么查询到的数量为 59。但通过上海服务器 C 进行查询的结果，却是 60。
待网络恢复后，服务器 A 和 B 的数据会同步到 C，C 更新数据为 59，最终三台服务器数据保持一致，用户刷新一下查询界面或重新提交一下查询，就可以得到最新的数据。而对用户来说，他们并不会感知到前后数据的差异，到底是因为其他用户购买导致的，还是因为网络故障导致数据不同步而产生的。
如果上海服务器等网络恢复后，再响应用户请求，如果用户提交一个查询请求，需要等上几分钟、几小时才能得到反馈，那么用户早已离 去了。 这种场景适合优先保证 AP，因为如果等到数据一致之后再给用户返回的话，用户的响应太慢，可能会造成严重的用户流失。
采用保 AP 弃 C 的系统也有很多，比如 CoachDB、Eureka、Cassandra、 DynamoDB 等。
对比分析
知识扩展：CAP 和 ACID 的“C”“A”是一样的吗？
CAP 中的 C 和 ACID 中的 C ：
- CAP 中的 C 强调的是数据的一致性，集群中节点之间通过复制技术保证每个节点上的数据在同一时刻是相同的。
- ACID 中的 C 强调的是事务执行前后，数据的完整性保持一致或满足完整性约束。不管在什么时候，不管并发事务有多少，事务在分布式系统中的状态始终保持一致。
CAP 中的 A 和 ACID 中的 A：
- CAP 中的 A 指的是可用性（Availability），系统提供的服务一直处于可用状态， 即对于用户的请求可即时响应。
- ACID 中的 A 指的是原子性（Atomicity），强调的是事务要么执行成功，要么执行失败。
总结
