CAP定理

概念

CAP 定理指出，在分布式系统中，系统只能在以下三个属性中同时保证两个：

一致性（Consistency，C）：所有节点看到相同的数据。对任一节点的写入操作，其后的所有读取都会返回更新后的值。

可用性（Availability，A）：每个发给非故障节点的请求都会得到响应，但不保证响应包含最新数据。

分区容错性（Partition Tolerance，P）：即使节点间发生网络分区或消息丢失，系统仍能继续运行。

在理想情况下（网络永不中断），可以同时拥有 C 和 A。但在实际环境中，网络延迟或中断不可避免，因此 P 通常被视为默认前提。真正的取舍在于 A 与 C：当网络分区发生时，是优先保证一致性，还是优先保证可用性？

一致性优先场景

• 票务系统（如 12306）：若两个用户同时预订同一座位，系统必须确保只有一个用户成功，以避免重复分配。

• 账户余额：扣款成功后，用户在任何终端查询余额都应反映扣款后的最新结果

可用性优先场景

• 社交媒体：用户更新个人信息后，短时间内其他用户可能仍看到旧信息，但系统不会返回错误。

• OLAP 系统：处理海量报表数据时，由于同步延迟，系统可能无法实时反映最新写入，但仍能提供历史数据查询，保证系统可用性。

一致性的补充说明

CAP 定理中所指的一致性通常是强一致性，即所有读取操作都反映最新写入。除此之外，还有其他一致性模型：

强一致性（Strong Consistency）

所有读取均返回最新写入的数据，开销较大，但对银行账户等需要绝对准确性的系统至关重要。

因果一致性（Causal Consistency）

• 保证具有因果关系的操作顺序一致，但允许无因果关系的操作顺序不同。
• 因果相关操作：如用户先发帖，再有回复，系统保证先看到发帖再看到回复。
• 并发无关操作：如不同用户同时点赞不同帖子，其顺序可以在各节点不同。

特殊实现
读己所写（Read-Your-Own-Writes Consistency）：用户在同一会话中总能立即看到自己提交的更新。常用于社交媒体。

最终一致性（Eventual Consistency）：

系统在经过一段时间后最终达到一致状态，但短期内可能存在不一致数据。典型应用：ClickHouse、分布式缓存等。