理解CAP定理：系统设计中的一致性、可用性与分区容错性
内容提要
CAP定理指出，分布式系统在一致性、可用性和分区容错性中只能同时保证两项。由于网络分区不可避免，实际选择是在分区时偏向一致性（CP）或可用性（AP）。CP系统优先正确性，AP系统优先可用性。真实系统如Cassandra、DynamoDB提供可调一致性，设计时应根据数据特性和故障影响权衡。
延伸解读
CAP定理的适用边界
CAP定理主要针对分布式系统，对于单机数据库（如单机PostgreSQL）并不适用，因为单机不存在网络分区。因此，在设计系统时，应明确系统是否真正需要分布式架构。如果业务规模不需要跨节点复制，单机数据库可能更简单可靠，无需为CAP权衡而复杂化。
一致性并非只有强弱之分
CAP定理将一致性视为二元选择，但实际存在多种一致性模型，如最终一致性、读己之写一致性、因果一致性等。这些模型在强一致性和无一致性之间提供了中间选项。设计时可根据业务需求选择合适的一致性级别，而非简单地在CP和AP之间二选一。
分区罕见，延迟常存
网络分区在运维良好的系统中相对少见，但节点间的复制延迟和共识协议耗时是常态。CAP定理只关注分区时的取舍，但实际中，每次读写操作都在进行一致性与延迟的权衡。因此，设计时需考虑延迟对用户体验的影响，而不仅仅是分区时的行为。
权衡可操作级定制
现代分布式系统如Cassandra和DynamoDB允许对每个操作设置一致性级别，而非系统级统一选择。例如，Cassandra的QUORUM级别在一致性和可用性间取得平衡，而DynamoDB提供强一致和最终一致读选项。设计时可根据操作的重要性（如金融交易 vs 社交动态）灵活配置，实现更精细的权衡。
Q&A
CAP定理中的一致性是什么意思？
在CAP定理中，一致性（Consistency）指的是所有节点在同一时刻看到相同的数据，即每次读取要么返回最新写入的数据，要么返回错误，不会返回旧值。这与ACID中的一致性（数据完整性约束）不同。
为什么分布式系统不能同时满足一致性、可用性和分区容错性？
因为网络分区是不可避免的。当分区发生时，节点之间无法通信，此时如果保证一致性，节点必须拒绝请求以避免返回旧数据，从而牺牲可用性；如果保证可用性，节点会返回可能过期的数据，从而牺牲一致性。因此，在分区时只能二选一。
CP系统和AP系统有什么区别？分别适用于什么场景？
CP系统在分区时优先保证一致性，牺牲可用性，适用于金融交易、库存管理等对数据正确性要求极高的场景；AP系统在分区时优先保证可用性，牺牲一致性，适用于社交媒体、产品目录等对实时性要求不高的场景。
有哪些典型的CP和AP系统？
典型的AP系统包括Cassandra、CouchDB和DynamoDB，它们默认采用最终一致性；典型的CP系统包括ZooKeeper，它用于分布式协调，必须保证一致性。Google Spanner则通过特殊技术实现了全球强一致性，但需要大量基础设施投入。
Cassandra如何通过一致性级别来平衡一致性和可用性？
Cassandra允许开发者在每次读写操作时指定一致性级别，例如ALL要求所有副本确认，提供强一致性但可用性低；ONE只需一个副本确认，可用性高但一致性弱；QUORUM要求多数副本确认，是常见的平衡选择。
CAP定理有哪些局限性？
CAP定理的局限性包括：它只关注分区时的选择，而实际中延迟是持续存在的；它将一致性视为二元，但实际存在多种一致性模型（如最终一致性、因果一致性等）；分区在良好运维的系统中相对罕见，而延迟是常态。
在设计分布式系统时，如何应用CAP定理？
设计时应先确定关键故障模式：如果数据错误比服务不可用更严重，选择CP；如果可用性更重要，选择AP。同时考虑数据变化速度、分区频率和持续时间，并针对不同操作采用不同的一致性级别，例如金融交易用强一致，非关键读取用最终一致。
