学分布式架构，你不得不知道的CAP理论和BASE理论

最新推荐文章于 2024-04-01 14:06:28 发布

原创最新推荐文章于 2024-04-01 14:06:28 发布 · 714 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #java

分布式专栏收录该内容

7 篇文章

订阅专栏

本文深入探讨了分布式系统中的CAP理论，详细解释了一致性（C）、可用性（A）及分区容错性（P）的概念，并对比了Nacos、Eureka、Consul与Zookeeper等注册中心的选择依据。同时介绍了BASE理论作为CAP理论的一种实用折衷方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

分布式架构理论

CAP理论

CAP定理: 指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得

一致性（C）：所有节点都可以访问到最新的数据
可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
分区容错性（P）：除了全部整体网络故障，其他故障都不能导致整个系统不可用
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

在这里插入图片描述

CA： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的

CP: 如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统

AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

注册中心的选择

	Nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	CP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	心跳	TCP/HTTP/gRPC/Cmd	Keep Alive
雪崩保护	有	有	无	无
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
SpringCloud集成	支持	支持	支持	支持

分布式系统中P,肯定要满足，所以只能在CA中二选一
没有最好的选择，最好的选择是根据业务场景来进行架构设计
如果要求一致性，则选择zookeeper/Nacos，如金融行业 CP
如果要求可用性，则Eureka/Nacos，如电商系统 AP
CP ：适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据
AP: 互联网业务，比如信息流架构，不要求数据强一致，更想要服务可用

BASE理论

由来自 ebay 的架构师提出:CAP 中的一致性和可用性进行一个权衡的结果，核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

Basically Available(基本可用)
- 假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响
Soft state（软状态）
- 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时
Eventually consistent（最终一致性）
- 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值