Skip to main content

CAP

CAP 定理 是分布式系统设计中的一个基础性理论，它指出一个分布式系统在以下三个核心特性中，最多只能同时满足其中两个：

  1. Consistency (一致性)
  2. Availability (可用性)
  3. Partition Tolerance (分区容错性)

在实际的分布式环境中，网络分区几乎是必然发生的，这意味着设计系统时，你需要在一致性 (C) 和可用性 (A) 之间做出取舍。

1. C: Consistency (一致性)​

在 CAP 定理的上下文中，一致性指的是强一致性：

  • 定义: 无论客户端连接到哪个节点，所有客户端都能在同一时间看到相同的数据。
  • 实现方式: 当一个写操作成功后，该更新必须立即或同步地传播到系统中的所有其他副本节点，否则后续的读操作将返回错误或等待。
  • 牺牲 C 的后果: 系统可能会返回旧版本的数据。

2. A: Availability (可用性)​

  • 定义: 系统对于任何非故障节点的请求，都能在合理的时间内返回一个非错误的响应，即使这个响应不保证包含最新的写入数据(异步)。
  • 实现方式: 即使在某些节点出现故障或网络中断时，其余健康的节点仍然可以继续处理请求，保证服务不中断。
  • 牺牲 A 的后果: 在网络分区期间，为了保证数据一致性，系统可能会返回错误或超时（即拒绝服务）。

3. P: Partition Tolerance (分区容错性)​

  • 定义: 即使系统中的节点之间发生网络分区（即节点之间丢失或延迟通信，无法互相连接），系统仍能继续运行。
  • 重要性: 由于网络故障在分布式系统中是不可避免的，因此在设计现代分布式系统（如云计算和 NoSQL 数据库）时，P 是一个必须满足的属性。

⚖️ CAP 定理的权衡取舍 (Trade-offs)​

由于 P（分区容忍性）在实际环境中是必需的，所以分布式系统的设计通常是在 C 和 A 之间进行选择：

组合满足特性牺牲特性典型场景示例常见数据库示例
CP一致性（C） + 分区容忍性（P）可用性（A）金融交易、库存管理等需要强一致的系统MongoDB,Redis
AP可用性（A） + 分区容忍性（P）一致性（C）社交网络、推荐系统等可接受最终一致性Cassandra
CA一致性（C） + 可用性（A）分区容忍性（P）单机或无分区的场景，如传统数据库单节点 MySQL、PostgreSQL

总结: CAP 定理是理解 NoSQL 数据库和现代分布式架构的关键，它迫使工程师在系统设计的早期就明确做出取舍，以适应其特定的业务需求和故障模型。

BASE​

BASE 理论是 NoSQL 数据库系统设计的基础原则，是对其分布式设计哲学的概括。它是与关系型数据库强调的 ACID 属性相对立的。 BASE 是ap模型的理论基础 BASE 旨在通过牺牲强一致性来换取更高的可用性和可扩展性。

BASE 是以下三个特性的首字母缩写：

1. Basically Available (基本可用性)​

  • 含义： 系统保证在发生部分故障（例如，一些节点或网络链路故障）时，仍能对外提供服务，不会完全停机。
  • 侧重： 强调系统要始终保持运行，能够响应用户请求。
  • 实现： 这通常通过在多个节点上进行数据冗余和复制来实现。

2. Soft State (软状态/柔性事务)​

  • 含义： 系统中的数据状态可以处于一个不一致的中间状态，而不是必须立即保持强一致。
  • 侧重： 数据的状态允许随时间变化。副本之间的数据同步需要时间，因此在同步完成前，不同节点的数据可能存在差异。这种不一致的中间状态是允许存在的。
  • 对比： 与 ACID 要求事务提交后系统立即处于一个硬状态（强一致）相反。

3. Eventually Consistent (最终一致性)​

  • 含义： 系统不对任意时刻的读取操作保证数据是最新的。但是，如果系统停止所有新的写入操作，系统中的所有数据副本最终都会在某个时间点收敛到一致的状态。
  • 侧重： 保证数据的不一致性是暂时的，并且最终会得到修复。
  • 实现： 这通过异步复制和冲突解决机制来实现。

⚡ BASE 与 ACID 的对比​

特性BASE 理论 (NoSQL)ACID 属性 (关系型 SQL)
设计目标高可用性和可扩展性数据完整性和事务可靠性
核心原则基本可用、软状态、最终一致原子性、一致性、隔离性、持久性
一致性等级最终一致性 (接受短暂不一致)强一致性 (要求数据实时同步)
CAP 侧重AP (可用性 + 分区容忍性)CP/CA (牺牲部分可用性或分区容忍性)
典型应用社交网络、日志系统、高并发 Web 服务银行交易、库存管理、会计系统