目录
1、CAP理论
1.1、介绍
1.2、CAP的三种选择
1.3、CAP的注意事项
2、BASE理论
2.1、定义介绍
2.2、最终一致性的介绍
2.3、BASE的实现方式
2.4、与ACID的对比
3、CAP与BASE的联系
4、如何选择CAP
前言
在分布式系统中，CAP理论和BASE理论是指导系统设计的核心原则，分别从一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）以及最终一致性（Eventually Consistent）的角度，帮助开发者权衡分布式系统的特性。
如下图所示：
CAP理论指出分布式系统无法同时保证一致性、可用性和分区容错性，必须在CA中做出选择。
在网络分区时，系统通常选择AP或CP架构，如ZooKeeper是CP，Eureka是AP。
BASE理论则是在CAP基础上，接受在故障时损失部分可用性，允许数据的软状态和最终一致性，以实现大规模系统的可伸缩性。
1、CAP理论
1.1、介绍
CAP理论由计算机科学家 Eric Brewer 提出，指出在分布式系统中，最多只能同时满足以下三个特性中的两个。
对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：
1、一致性（Consistency） :
所有节点访问同一份最新的数据副本。
2、可用性（Availability）:非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
3、分区容错性（Partition Tolerance） :分布式系统出现网络分区的时候，仍然能够对外提供服务。
如下所示：
解决分区问题的最好办法就是给数据备份，备份在不同的网络中，这样，当网络通信出现故障，就会降低数据访问不到的风险，提高了分区容错性。
1.2、CAP的三种选择
-
CP（一致性 + 分区容错性）
-
保证数据强一致，但在网络分区时可能拒绝请求（牺牲可用性）。
-
典型系统：ZooKeeper、etcd、HBase。
-
-
AP（可用性 + 分区容错性）
-
保证高可用，但可能返回旧数据（牺牲强一致性）。
-
典型系统：Cassandra、DynamoDB、Eureka。
-
-
CA（一致性 + 可用性）
-
仅在无网络分区的单机或局域网环境中可行，分布式系统通常无法避免分区（P必须选择）。
-
1.3、CAP的注意事项
-
P是必须选择的：分布式系统一定会面临网络分区问题（如机房断网、节点宕机），因此实际选择是 CP 或 AP。
-
CAP是理论极限：实际系统可能动态调整（如降级策略）。
2、BASE理论
由于CAP理论中的强一致性（C）和高可用性（A）难以同时满足。
2.1、定义介绍
BASE理论（Basically Available, Soft state, Eventually consistent）提出了一种折中方案，适用于大规模分布式系统（如电商、社交网络）。
以下是介绍：
软状态允许数据备份延迟，但最终这些数据都要保证一致性。这就是最终一致性。
2.2、最终一致性的介绍
最终一致性在软状态上加了一个时限，这个时限取决于网络延时、系统负载、数据复制方案设计等。
根据实际的业务场景，最终一致性可被分为以下 5 种。
1、因果一致性
有果必有因。收到数据更新通知的节点，应该使用更新后的新值，即种下什么因，就得什么果。
例如，服务A更新了一个数据后，通知给了服务B，那么服务B如果要操作这个数据，应该使用 A 更新后的新值。如果 C 和 A没有这种关系，那么可以不受这一条件的限制。
2、读自身所写
自身写入的新值，之后读取也应该是这个新值。这是一种特殊的因果一致性。
3、会话一致性
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读自身所写”的一致性。
也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4、单调读一致性
单调读一致性是指，如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
5、单调写一致性
单调写一致性是指，一个系统要能够保证来自同一个节点的写操作被顺序的执行。
在实践中，这5种一致性往往会结合使用，以构建一个具有最终一致性的分布式系统。
2.3、BASE的实现方式
-
读写分离：写操作同步到主节点，读操作可能访问从节点（旧数据）。
-
异步复制：数据先写入主节点，再异步同步到从节点。
-
冲突解决：使用版本号（Vector Clock）、CRDT（无冲突数据类型）等机制处理冲突。
2.4、与ACID的对比
3、CAP与BASE的联系
-
CAP是理论框架，指出分布式系统必须权衡一致性、可用性和分区容错性。
-
BASE是工程实践，在AP系统（高可用）的基础上，通过最终一致性平衡性能与一致性。
CAP选择
-
牺牲部分可用性（A）：在网络分区或选举期间，ZooKeeper 可能暂时不可用（返回错误或阻塞请求）。
Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。
因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
4、如何选择CAP
-
需要强一致性（CP）：金融交易、分布式锁（如etcd）。
-
需要高可用性（AP）：社交网络、商品库存（如Cassandra）。
-
最终一致性（BASE）：评论系统、消息队列（如Kafka）。
总结
CAP理论：分布式系统必须牺牲C或A，P不可放弃。
BASE理论：通过最终一致性实现高可用，适合对实时一致性要求不高的场景。
现代系统趋势：
混合模式（如TiDB：Raft保证CP，但通过优化提供高可用）。
动态调整（如网络恢复后自动修复一致性）。
参考文章：
1、【分布式】CAP理论和BASE理论详解_cap和base理论区别-CSDN博客
https://blog.csdn.net/kazuhura/article/details/129771346?ops_request_misc=&request_id=&biz_id=102&utm_term=cap%E7%90%86%E8%AE%BA%E5%92%8Cbase%E7%90%86%E8%AE%BA&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-1-129771346.142^v102^pc_search_result_base1&spm=1018.2226.3001.4187
Base85)
环境安装与demo)
