分布式基础-详解CAP定理与应用场景分析

朋友，你是不是一样呢？ 废话少说：

---

---

什么是分布式系统

最简单的事例，就比如我们的商品管理系统。之前的系统是包含了所有的功能，比如用户注册登录、管理员功能、物品管理等等。这叫做集中式系统。也就是一个人干好几件事。

后来随着功能的增多，用户量也越来越大。集中式系统维护太麻烦，拓展性也不好。于是就考虑着把这些功能进行划分。通俗的理解就是原本需要一个人干的事，现在分给n个人干，各自干各自的，最终取得和一个人干的效果一样。

正规一点的定义是：一个业务拆分多个子业务，部署在不同的服务器上。 然后通过一定的通信协议，能够让这些子业务之间相互通信。

既然分给了n个人，那就涉及到这些人的沟通交流协作问题。想要去解决这些问题，就需要先了解分布式系统中的CAP理论，给后面Zookeeper或者部分的中间件，埋下一个小小的伏笔。分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。壮士，千万不要被这个看起来高大上的概念迷惑住。

举个小例

首先我们看一张图。

网络中有两个节点N1和N2，之间的网络是可以连通的，N1中有个应用程序A，和一个数据库V，N2也有个应用程序B2和一个数据库V。现在，A和B是分布式系统的两个部分，V是分布式系统的两个子数据库:

那么问题来了。突然有两个用户小明和小华分别要同时访问了N1和N2。理想的操作是下面这样：

（1）小明访问N1节点，小华访问N2节点。同时访问的;

（2）小明把N1节点的数据V0变成了V1;

（2）N1节点一看自己的数据有变化，马上执行M操作，告诉了N2；

（4）小华读取到的就是最新的数据。也是正确的数据。

上面是种最理想的情景。它满足了CAP理论的三个特性。但对于一个分布式系统来说，是不可能满足以下的三点：

• Consisteny（一致性）
• Availability（可用性）
• Partition tolerance（分区容错性）

也就是说CAP定理指明了，任何分布式系统只能同时满足这三项中的两项：

Consistency 和 Availability 的矛盾
一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。
如上图，如果是最多同时满足两项，那我们可以有三个组合：CA、CP、AP。在聊这三个组合之前，分别解释每个指标;

一致性（Consistency）

这里指的是强一致性，最终一致性后续讨论。
在写操作完成后开始的任何读操作都必须返回该值，或者返回后续写操作的结果。
也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据：

如下系统来进行解释:

• 客户端向G1写入数据v1，并等待响应，此时，
• G1服务器的数据为v1，而G2服务器的数据为v0，两者是不一致，接着，
• 在返回响应给客户端之前，G2服务器会自动的同步G1服务器数据，使得G2服务器的数据也是v1；
  
• 一致性保证了不管是哪台服务器（比如G1）写入数据，其他的服务器（G2）能实时同步数据；
  
• G2已经同步了G1的数据，会告诉G1，已经同步;
• G1接收了所有同步服务器的已同步报告，才将“写入成功”信息响应给client;
• client再发起请求，读取G2的数据;
• 此时得到的响应是v1，虽然client从未写入数据到G2；

分区容错性（Partition tolerance）

允许网络丢失从一个节点发送到另一个节点的任意多条消息，即不同步
也就是说，G1和G2发送给对方的任何消息都是可以放弃的，也就是说G1和G2可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bos41J9s-1623048751090)(https://gitee.com/alotlong/picture/raw/master/2021-5-9/1620541072947-%E5%88%86%E5%8C%BA%E5%AE%B9%E9%94%99.png)]

可用性（Availability）

系统中非故障节点收到的每个请求都必须有响应
，所以在可用系统中，如果我们的客户端向服务器发送请求，并且服务器未崩溃，则服务器必须最终响应客户端，不允许服务器忽略客户的请求：

CAP三者不可能同时满足
假设确实存在三者能同时满足的系统

那么我们要做的第一件事就是分区我们的系统，因为是满足分区容错性的，也就是说可能因为通信不佳等情况，G1和G2之间是没有进行同步：

接下来，我们的客户端将v1写入G1，但G1和G2之间是不同步的，所以如下G1是v1数据，G2是v0数据：

由于要满足可用性，即一定要返回数据，所以G1必须在数据没有同步给G2的前提下返回数据给client：

接下去，client请求的是G2服务器，由于G2服务器的数据是v0，所以client得到的数据是v0：

验证CAP理论

既然系统总是会有错误，那我们就来看看可能会出现什么错误。

N1节点更新V0到V1，想在也想把这个消息通过M操作告诉N1节点，却发生了网络故障。这时候小明和小华都要同时访问这个数据，怎么办呢？现在我们依然想要我们的系统具有CAP三个特性，我们分析一下会发生什么：

（1）系统网络发生了故障，但是系统依然可以访问，因此具有容错性。

（2）小明在访问节点N1的时候更改了V0到V1，想要小华访问节点N2的V数据库的时候是V1，因此需要等网络故障恢复，将N2节点的数据库进行更新才可以。

（3）在网络故障恢复的这段时间内，想要系统满足可用性，是不可能的。因为可用性要求随时随地访问系统都是正确有效的,这就出现了矛盾。

正是这个矛盾所以CAP三个特性肯定不能同时满足。既然不能满足，那我们就进行取舍。

有两种选择：

牺牲数据一致性，也就是小明看到的衣服数量是10，买了一件应该是9了。但是小华看到的依然是10。
牺牲可用性，也就是小明看到的衣服数量是10，买了一件应该是9了。但是小华想要获取的最新的数据的话，那就一直等待阻塞，一直到网络故障恢复。

现在你可以看到了CAP三个特性肯定是不能同时满足的，但是可以满足其中两个;

如何权衡

三选二利弊如何

CA：关注一致性和可用性，它需要非常严格的全体一致的协议，比如“两阶段提交”（2PC）。CA 系统不能容忍网络错误或节点错误，一旦出现这样的问题，整个系统就会拒绝写请求，因为它并不知道对面的那个结点是否挂掉了，还是只是网络问题，存在二义性。唯一安全做法就是把自己变成只读的。
CP：关注一致性和分区容忍性。它关注的是系统里大多数人的一致性协议，比如：Paxos 算法 (Quorum 类的算法)。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性；
AP：这样的系统关心可用性和分区容忍性。因此，这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据的版本。

权衡三者的关键点取决于业务

放弃一致性，满足分区容错，那么节点之间就有可能失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会容易导致全局数据不一致性。

对于互联网应用来说（如网易），机器数量庞大，节点分散，网络故障再正常不过了，那么此时就是保障AP，放弃C的场景，而从实际中理解，像门户网站这种偶尔没有一致性是能接受的，但不能访问问题就非常大了。

对于银行来说，就是必须保证强一致性，也就是说C必须存在，那么就只用CA和CP两种情况，当保障强一致性和可用性（CA），那么一旦出现通信故障，系统将完全不可用。另一方面，如果保障了强一致性和分区容错（CP），那么就具备了部分可用性。实际究竟应该选择什么，是需要通过业务场景进行权衡的（并不是所有情况都是CP好于CA，只能查看信息但不能更新信息有时候还不如直接拒绝服务）。

---

【公众号：码工是小希】建立了读者技术交流群，群内会有各种大佬在线Batte解答疑问,更有号主呕心沥血整理的超500G精品资料汇总等你来拿，没有套路的那种，白嫖的不香吗； 特色：每天群里会组织技术问答活动，累计积分更够奖金到手，相信你能慢慢的积累，最终厚积薄发的！还能侃职场，反正各种合法的瞎聊（禁止广告）。技术推文允许进入；

备注：“进群”即可

如果本文对大家有那么一点点帮助，
请一定给个 点赞 + 再看 支持呀 谢谢你！