一句话总结:就是因为做不到真正意义上的同步,所以说要不得舍弃可用性等同步,要不得舍弃一致性不等同步让他能用
初始理解CAP定理
在分布式系统中，CAP定理是一个基本原理，它指出在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三个特性无法同时完全满足，最多只能同时满足其中的两个。具体来说：
- 一致性（Consistency）：所有节点在同一时间看到的数据是相同的。也就是说，任何读取操作都能返回最新的写入结果。
- 可用性（Availability）：每个请求都能得到响应，无论成功或失败，系统总是在可接受的时间内返回结果。
- 分区容忍性（Partition tolerance）：系统在遇到网络分区（即部分节点无法与其他节点通信）时，仍然能够继续运行。
CAP定理的核心
CAP定理的核心在于，当网络分区发生时（这是分布式系统中不可避免的），系统必须在一致性和可用性之间做出选择：
选择CP（一致性和分区容忍性）：当网络分区发生时，系统会停止部分操作以确保数据的一致性。这意味着某些节点可能无法提供服务，从而牺牲了可用性。例如，一些数据库系统在分区时会停止写入操作，直到分区恢复，以确保数据的一致性。
选择AP（可用性和分区容忍性）：当网络分区发生时，系统会继续提供服务，但可能会返回不一致的数据。这意味着系统可能会提供旧的数据或部分数据，以保持高可用性。例如，一些NoSQL数据库在分区时会允许读取和写入，但不同分区之间的数据可能会暂时不一致。
为什么不能同时满足CAP？
在分布式系统中，网络分区是一个现实问题，无法完全避免。因此，分区容忍性（P）是必须考虑的。这就迫使我们在一致性和可用性之间做出权衡：
如果选择一致性（C）：在网络分区时，为了确保所有节点数据一致，系统可能需要阻止某些操作（如写入），直到分区恢复。这会降低可用性（A）。
如果选择可用性（A）：在网络分区时，系统允许继续读写操作，但不同分区的数据可能会不一致，从而牺牲一致性（C）。
实际系统中的CAP选择
不同的分布式系统根据其设计目标会选择不同的CAP组合：
CP系统：如ZooKeeper、HBase等。这些系统在网络分区时会优先保证一致性，可能会拒绝部分请求。
- 例子：ZooKeeper在选举leader时，如果无法达成多数派共识，会停止服务以确保一致性。
AP系统：如Cassandra、Dynamo等。这些系统在网络分区时会优先保证可用性，允许读取和写入，但可能会返回不一致的数据。
- 例子：Cassandra在分区时会允许写入，但不同节点可能会有暂时不一致的数据，后续通过冲突解决机制（如“最后写入获胜”）解决。
CA系统：传统单机数据库（如MySQL主从架构，无分区时）。这类系统通常不考虑分区容忍性，因为它们在单数据中心内运行，假设网络是可靠的。但在分布式环境中，CA系统无法真正实现。
分区容忍性的重要性
分区容忍性（P）是分布式系统的基本要求，因为：
- 网络是不可靠的：分布式系统的节点之间通过网络通信，网络延迟、丢包、分区是常态。
- 扩展性需求：分布式系统通常需要跨地域部署，网络分区的概率更高。
因此，实际中大多数分布式系统需要在CP或AP之间选择。
CAP的误解与澄清
CAP不是“三选二”：CAP并不是说任何时候都可以选择两个特性，而是说在网络分区发生时必须在C和A之间选择。在无分区时，可以同时满足CA。
CAP不是绝对的：现代分布式系统通常通过折中设计（如最终一致性、读写分离）在C和A之间找到平衡。例如：
- 最终一致性：系统暂时放松一致性要求，通过异步复制逐步达到一致（如DNS、Cassandra）。
- 读写分离：读操作可以读取旧数据（高可用），写操作需要强一致性（如Riak）。
例子分析
以银行转账系统为例：
- 选择CP：如果网络分区导致无法确认转账是否成功，系统会拒绝转账操作（牺牲可用性），确保不会出现数据不一致（如重复扣款或未扣款）。
- 选择AP：系统允许转账操作，但可能暂时无法同步到所有节点，导致部分用户看到不一致的余额（如一方扣款但另一方未到账）。
现代分布式系统的实践
现代分布式系统通常采用更灵活的设计：
BASE理论：Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）。这是对CAP中AP的扩展，允许系统在分区时降级服务，最终恢复一致性。
- 例子：电商库存系统可能允许超卖（AP），后续通过补偿机制（如取消订单）恢复一致性。
多副本策略：
- 强一致性：如Raft协议，要求多数派确认写入（CP）。
- 弱一致性：如Gossip协议，允许异步复制（AP）。
总结
CAP定理揭示了分布式系统设计的根本限制：在网络分区发生时，必须在一致性和可用性之间做出选择。理解这一点有助于：
- 根据业务需求选择适合的分布式系统（如金融系统偏向CP，社交网络偏向AP）。
- 设计系统时明确权衡点，避免不切实际的期望（如同时实现强一致性和高可用性）。
- 采用灵活的一致性模型（如最终一致性）在特定场景下优化体验。
最终回答
CAP定理指出，在分布式系统中，一致性（C）、可用性（A）和分区容忍性（P）无法同时完全满足。由于网络分区是不可避免的（P必须接受），系统必须在C和A之间选择：
- 选择CP：在网络分区时保证一致性，可能牺牲可用性（如拒绝部分请求）。
- 选择AP：在网络分区时保证可用性，可能牺牲一致性（如返回旧数据或部分数据）。
实际系统中，通常根据业务需求选择：
- 强一致性场景（如金融系统）：偏向CP。
- 高可用性场景（如社交网络）：偏向AP。
- 折中方案：如最终一致性（AP的扩展）或读写分离（部分满足C和A）。
CAP定理的核心是理解分布式系统的设计约束，并在实际中做出合理的权衡。