分布式系统中CAP理论与BASE理论

最新推荐文章于 2025-06-03 15:46:28 发布

tazj

最新推荐文章于 2025-06-03 15:46:28 发布

阅读量676

点赞数 19

分类专栏：系统设计文章标签：分布式 java 数据库 mysql

本文链接：https://blog.youkuaiyun.com/tazj666/article/details/144798495

版权

系统设计专栏收录该内容

2 篇文章

订阅专栏

CAP理论（即一致性、可用性和分区容忍性理论）是分布式系统中一个非常重要的理论，由计算机科学家Eric Brewer提出。CAP理论表明，对于一个分布式系统来说，在一致性（C）、可用性（A）和分区容忍性（P）三者之间，最多只能同时满足两项，无法同时保证三项。

一致性（Consistency）：一致性意思就是写操作之后进行读操作无论在哪个节点都需要返回写操作的值
一致性指的是在分布式系统中，所有节点在同一时刻都能够看到相同的数据状态。也就是说，当一个数据更新操作完成后，系统中的所有节点都能够立刻访问到最新的数据。
可用性（Availability）：非故障的节点在合理的时间内返回合理的响应
可用性指的是系统能够在任何时刻都能对客户端提供服务，哪怕部分节点出现故障，系统也能保证其他节点继续对外提供服务，不会因为某个节点的故障而导致整个系统不可用。
分区容忍性（Partition Tolerance）：当网络出现分区后，系统依然能够继续旅行社职责
分区容忍性指的是即使网络中存在分区（即某些节点之间无法直接通信），系统仍然能够正常运行。换句话说，系统应该能继续处理请求，即使一些节点因为网络问题与其他节点无法通信。

CAP定理的三大权衡：

根据CAP理论，任何分布式系统都只能选择以下三种之一：

CA（Consistency + Availability）：系统在没有网络分区的情况下，保证数据一致性和可用性。常见于一些小规模或者集中式的分布式系统（例如，数据库集群的情况）。
CP（Consistency + Partition Tolerance）：系统在网络分区发生时保证一致性和分区容忍性，但可能牺牲可用性（例如，Zookeeper、HBase）。
AP（Availability + Partition Tolerance）：系统在网络分区发生时保证可用性和分区容忍性，但可能牺牲一致性（例如，Cassandra、Couchbase）。

经典的例子：

CA：传统的单点数据库系统，它能够提供一致性和可用性，但如果网络出现问题或者扩展到多个数据中心时，它会受到限制。
CP：例如，HBase，它保证数据的一致性，并在出现分区时，依然能够正常工作，但在网络不通时，它的可用性可能会受到影响。
AP：例如，Cassandra，它保证系统在出现分区时仍能提供服务，但是在一些情况下，数据一致性可能会被牺牲，最终的数据可能需要通过后台机制进行修复。

总结：

CAP理论的核心思想是，分布式系统必须在一致性、可用性和分区容忍性之间做出选择。系统架构师在设计系统时，需要根据具体的业务需求和场景来权衡这些属性。

1.在分布式系统中有多个节点、服务，这些服务中有的宕机了不会影响其它的系统，这是分布式天然支持的，他就是P，因此只要是分布式系统就一定有P，而ACP理论就是说ACP不可能同时成立，只会有AP与CP。而这个AC只在单节点下存在（例如MySQL单机）。

2.但是现代互联网项目中不可能只要AP或CP（但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。CP），需要一个三者间的平衡点，让A和C都做成一下妥协，就是BASE理论。

当P发生的时候就是服务A与服务B之间不能通信了，即这个同步不能进行了，这个时候如果要保证C一致性，服务B就不能对外服务了；如果要保证A可用性，那两者的数据就出现不一致了。

BASE理论是Basically Available、Soft state、Eventual consistency的缩写。它强调的是系统在分布式环境下的一致性与可用性的平衡，特别是面临高可用性和高性能的需求时。

BASE理论的三大要素：

Basically Available（基本可用）：
- 基本可用指的是系统在大多数情况下能够提供服务。即使在某些情况下，系统的某些部分可能会不可用，整体系统仍然能够继续响应客户端的请求。
- 在BASE理论中，“基本可用”并不要求系统在任何时刻都完美地响应所有请求，而是保证系统在大部分情况下可用，即使某些部分出现故障，系统仍然能够提供服务。
示例：例如，Cassandra等分布式数据库，某些节点由于故障或网络问题无法访问，但其他节点仍然可以继续提供服务。系统可以将部分请求转发给其他可用的节点，尽管在极端情况下某些数据可能暂时不可用。
Soft State（软状态）：
- 软状态意味着系统的状态可能会在一段时间内保持不一致，系统的状态是动态变化的，且在某些情况下，系统可以暂时存储不一致的数据。也就是说，系统不会强制立即确保所有数据一致，而是允许在某些时间窗口内存在“软”状态。
- 这种状态是可以随时间变化的，系统通过异步处理、后台任务等机制来逐步修复不一致的数据。
示例：在许多分布式数据库（如Cassandra、Couchbase等）中，写操作会被异步地传播到其他节点，因此某些节点的状态可能会在短时间内与其他节点不一致。这种不一致会随着时间逐渐被修复，因此被称为“软状态”。
Eventual Consistency（最终一致性）：
- 最终一致性意味着系统最终会达到一致的状态，但并不要求在所有时刻都保持一致。当数据在系统中的多个副本之间传播时，系统允许短期内的数据不一致，但最终这些副本将被同步，以确保数据一致性。
- 最终一致性通常通过后台的同步机制（如Gossip协议、合并算法等）来实现。
示例：比如在Amazon Dynamo数据库中，写入的数据可能会在不同的数据副本之间存在短时间的不一致，但系统通过后台的同步和冲突解决机制确保所有副本最终达成一致。