分布式技术之CAP理论
2023-12-30 10:30:47
- CAP 理论指导分布式系统的设计,以保证系统的可用性、数据一致性等特征。比如电商系统中,保证用户可查询商品数据、保证不同地区访问不同服务器查询的数据是一致的等。
什么是 CAP?
- 结合电商的例子,带你理解 CAP 的含义。假设某电商,在北京、杭州、上海三个城市建立了仓库,同时建立了对应的服务器{A, B, C}用于存储商品信息。比如,某电吹风在北京仓库有 20 个,在杭州仓库有 10 个,在上海仓库有 30 个。那么,CAP 这三个字母在这个例子中分别代表什么呢?
- 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 理论又是什么呢?
- CAP 理论指的就是,在分布式系统中 C、A、P 这三个特征不能同时满足,只能满足其中两个,如下图所示。这,是不是有点像分布式系统在说,这顶“帽子”我不想要呢?
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 返回给用户,等到网络恢复,再进行数据同步。
- 第一种处理方式是,保证一致性 C,牺牲可用性 A:Server2 选择让 User2 的请求阻塞,一直等到网络恢复正常,Server1 被修改的数据同步更新到 Server2 之后,即 DB2 中数据 a 修改成最新值 2 后,再给用户 User2 响应。
- 除了以上这两种方案,没有其他方案可以选择。可以看出:在满足分区容错性 P 的前提下,一致性 C 和可用性 A 只能选择一个,无法同时满足。
CAP 选择策略及应用
- 分布式系统无法同时满足 CAP 这三个特性,那该如何进行取舍呢?
- C、A 和 P,没有谁优谁劣,只是不同的分布式场景适合不同的策略。接下来,以一些具体场景为例,分别介绍保 CA 弃 P、保 CP 弃 A、保 AP 弃 C 这三种策略,以面对不同的分布式场景时,知道如何权衡这三个特征。
- 对于涉及钱的交易时,数据的一致性至关重要,因此保 CP 弃 A 应该是最佳选择。而对于其他场景,大多数情况下的做法是选择 AP 而牺牲 C,因为很多情况下不需要太强的一致性(数据始终保持一致),只要满足最终一致性即可。最终一致性指的是,不要求集群中节点数据每时每刻保持一致,在可接受的时间内最终能达到一致就可以了。
- 这个方案中,在应用节点之间引入了消息中间件,不同节点之间通过消息中间件进行交互,比如主应用节点要执行修改数据的事务,只需要将信息推送到消息中间件,即可执行本地的事务,而不需要备应用节点同意修改数据才能真正执行本地事务,备应用节点可以从消息中间件获取数据。
保 CA 弃 P
- 在分布式系统中,现在的网络基础设施无法做到始终保持稳定,网络分区(网络不连通)难以避免。牺牲分区容错性 P,就相当于放弃使用分布式系统。因此,在分布式系统中,这种策略不需要过多讨论。
- 既然分布式系统不能采用这种策略,那单点系统毫无疑问就需要满足 CA 特性了。比如关系型数据库 DBMS(比如 MySQL、Oracle)部署在单台机器上,因为不存在网络通信问题,所以保证 CA 就可以了。
保 CP 弃 A
- 如果一个分布式场景需要很强的数据一致性,或者该场景可以容忍系统长时间无响应的情况下,保 CP 弃 A 这个策略就比较适合。
- 一个保证 CP 而舍弃 A 的分布式系统,一旦发生网络分区会导致数据无法同步情况,就要牺牲系统的可用性,降低用户体验,直到节点数据达到一致后再响应用户。
- 这种策略通常用在涉及金钱交易的分布式场景下,因为它任何时候都不允许出现数据不一致的情况,否则就会给用户造成损失。因此,这种场景下必须保证 CP。保证 CP 的系统有很多,典型的有 Redis、HBase、ZooKeeper 等。
ZooKeeper是如何保证 CP 的
- ZooKeeper 架构图
- ZooKeeper 集群包含多个节点(Server),这些节点会通过分布式选举算法选出一个 Leader 节点。在 ZooKeeper 中选举 Leader 节点采用的是 ZAB 算法。
- 在 ZooKeeper 集群中,Leader 节点之外的节点被称为 Follower 节点,Leader 节点会专门负责处理用户的写请求:
- 当用户向节点发送写请求时,如果请求的节点刚好是 Leader,那就直接处理该请求;
- 如果请求的是 Follower 节点,那该节点会将请求转给 Leader,然后 Leader 会先向所有的 Follower 发出一个 Proposal,等超过一半的节点同意后,Leader 才会提交这次写操作,从而保证了数据的强一致性。
- 当出现网络分区时,如果其中一个分区的节点数大于集群总节点数的一半,那么这个分区可以再选出一个 Leader,仍然对用户提供服务,但在选出 Leader 之前,不能正常为用户提供服务;如果形成的分区中,没有一个分区的节点数大于集群总节点数的一半,那么系统不能正常为用户提供服务,必须待网络恢复后,才能正常提供服务。这种设计方式保证了分区容错性,但牺牲了一定的系统可用性。
保 AP 弃 C
- 如果一个分布式场景需要很高的可用性,或者说在网络状况不太好的情况下,该场景允许数据暂时不一致,那这种情况下就可以牺牲一定的一致性了。网络分区出现后,各个节点之间数据无法马上同步,为了保证高可用,分布式系统需要即刻响应用户的请求。但,此时可能某些节点还没有拿到最新数据,只能将本地旧的数据返回给用户,从而导致数据不一致的情况。
- 适合保证 AP 放弃 C 的场景有很多。比如,很多查询网站、电商系统中的商品查询等,用户体验非常重要,所以大多会保证系统的可用性,而牺牲一定的数据一致性。
- 目前,采用保 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),强调的是事务要么执行成功,要么执行失败。
因此,CAP 和 ACID 中的“C”和“A”是不一样的,不能混为一谈。
你知道的越多,你不知道的越多。
文章来源:https://blog.csdn.net/qq_40722827/article/details/135248071
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!