梗概
- 是一个分布式系统的设计理念
- CAP 是 Consistency（一致性）、Availability（可用性）和 Partition Tolerance（分区容错性）的首字母缩写。
- CAP 定理指出，在一个分布式系统中，这三者无法同时完美实现，最多只能同时满足其中的两项。
具体来说：
- 一致性（Consistency）：所有节点在同一时间看到的数据是一致的，即数据在所有节点上是同步的。
- 可用性（Availability）：系统始终能够响应每一个请求，即使部分节点出现故障。
- 分区容错性（Partition Tolerance）：系统能够容忍网络分区故障，即即使系统中部分节点之间的网络通信出现问题，系统仍能正常工作。
关键点
CAP 定理的关键点在于：在一个存在网络分区的情况下（几乎所有分布式系统都会面临网络分区问题），设计者必须在一致性和可用性之间做出权衡。根据不同的业务需求，系统通常会选择侧重于一致性（如银行系统）或可用性（如社交网络）。 常见的分布式系统设计中：
- 强调一致性的系统往往会牺牲一定的可用性，如一些基于 Paxos 或 Raft 协议的系统。
- 强调可用性的系统通常会放松对一致性的要求，如一些 NoSQL 数据库（Cassandra、DynamoDB 等）。 总结来说，CAP 定理为分布式系统的设计提供了一个基础框架，帮助开发者在一致性、可用性和分区容错性之间进行合理的取舍。
不一致的后果
- 数据不一致：在不同节点或副本之间，数据可能会暂时不同步。这意味着用户在不同的节点上看到的数据可能会不一致。例如，一个用户可能在某个节点上看到更新后的信息，而另一个用户在不同的节点上看到旧的信息。
- 业务逻辑复杂性：为了处理数据的不一致，应用程序需要实现复杂的同步和冲突解决机制。这增加了系统的复杂性，可能导致更多的代码维护和调试工作。
- 用户体验问题：在系统中存在数据不一致时，用户可能会遇到不同的应用行为或数据状态。这种体验上的不一致可能会使用户感到困惑或不信任系统。
- 数据冲突：在最终一致性模型下，系统通常需要进行冲突检测和解决。数据冲突可能需要额外的业务逻辑来确定最终的正确状态，增加了实现的复杂性。
- 测试难度：确保系统在面对数据不一致时仍能正常工作，可能需要更复杂的测试场景。这使得测试过程变得更加困难和耗时。
- 性能影响：为了解决不一致的问题，系统可能需要额外的网络通信和数据同步，这可能会影响系统的性能和响应时间。
示例
- 如用户的剩余积分不一致时, 用户可以从A节点兑换物品, 然后再去B节点兑换物品, 再去C节点兑换物品…
示例
为了更好地理解 CAP 定理，以下是几个常见的分布式系统示例，说明如何在一致性、可用性和分区容错性之间进行权衡：
示例 1: 强一致性（C）和分区容错性（P）——牺牲可用性（A）
系统选择保证一致性和分区容错性，比如一些分布式数据库如 HBase 和 MongoDB（默认配置下）。 场景：在金融交易系统中，数据的一致性是至关重要的。如果网络分区发生，系统会牺牲可用性，拒绝处理请求，直到数据在所有节点中同步完成，确保所有用户看到的数据都是一致的。 权衡：这种系统下，当网络不稳定时，系统可能会暂时不可用（如某个分区内的数据无法访问），但不会出现数据不一致的问题。
示例 2: 可用性（A）和分区容错性（P）——牺牲一致性（C）
一些注重高可用性和分区容错性的系统，如 Cassandra 和 DynamoDB，在网络分区时牺牲一致性。 场景：在社交媒体平台上，用户发送的评论、点赞等操作要求系统响应迅速，用户体验流畅。即使某些节点数据未同步，系统仍会继续提供服务，稍后再进行数据的同步更新。这意味着不同用户在不同节点可能会暂时看到不同的状态（如点赞数不完全一致）。 权衡：这种系统倾向于最终一致性（Eventual Consistency），即在网络问题解决后，系统最终会达到一致状态，而不是立即一致。
示例 3: 一致性（C）和可用性（A）——牺牲分区容错性（P）
一些传统的集中式数据库（如单节点的 MySQL 或 PostgreSQL）可以看作是这种模型。 场景：在一个小型应用中，数据库部署在单一服务器上，没有考虑分布式和网络分区问题。系统确保所有请求都是一致且可用的，但一旦网络故障或服务器分区（如断网）发生，整个系统会变得不可用。 权衡：这种架构下，分区容错性被牺牲，一旦系统发生网络分区，服务就无法继续运行。
总结：
CAP 定理为系统设计者提供了一个清晰的框架，以在实际业务需求中做出合理的权衡。没有完美的解决方案，设计者需要根据具体的业务场景选择优先满足的特性。
视频
- 【CAP理论还迷糊，那不怪你！| CAP定理 | 分布式系统-哔哩哔哩】 https://b23.tv/jaEnZij