在分布式系统中，CAP定理告诉我们不可能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三者，只能选择其中两个。云数据库选型的核心就是根据业务需求在CAP之间做权衡：对一致性要求高的场景选CP系统如MongoDB的强一致模式或TiDB；追求高可用性的选AP系统如Cassandra或DynamoDB；实际中多采用最终一致性模型，在分区时优先保证可用，通过异步复制实现数据同步。选型时，先评估业务对读写一致性的敏感度、故障恢复需求和数据规模，选择如CP的NewSQL或AP的NoSQL来平衡。

从CAP定理看云数据库选型

CAP理论由Eric Brewer提出，后由Gilbert和Lynch正式证明。在分布式环境下，网络分区（P）是不可避免的，因此系统设计必须在C（一致性，所有节点数据相同）和A（可用性，每请求都有响应）之间取舍。传统关系型数据库如MySQL在单机下是CA，但分布式时需引入复制和分片，牺牲部分一致性。云数据库如阿里云PolarDB采用多活架构，在分区时优先A，通过读写分离和最终一致性来权衡。

一致性 vs 可用性：实际案例

电商场景下，库存扣减需要强一致性（CP），否则超卖；社交Feed可用性优先（AP），允许短暂不一致。选型时，CP系统如CockroachDB保证线性一致性，但读写延迟高；AP系统如ScyllaDB提供低延迟高吞吐，但需业务层补偿不一致。权衡之道是分库分表：核心交易用CP，非核心用AP。

云厂商数据库CAP实践

AWS DynamoDB是典型AP系统，支持最终一致性和强一致性读选项，分区时保证99.99%可用性。腾讯云TDSQL是CP+AP混合，支持分布式事务。华为云GaussDB提供HTAP能力，在分区故障时自动切换主备，优先恢复可用性。选型建议：高并发读写选AP，低延迟事务选CP。

分区容忍下的优化策略

分区发生时，CP系统可能拒绝服务以保一致，AP系统继续响应旧数据。优化包括：使用Gossip协议检测分区、Quorum读写（如N=3，W=2,R=2保证一致）、多地域部署减少分区概率。实际中，BASE模型取代ACID，强调Basically Available、Soft state、Eventual consistency。

选型流程与权衡框架

1. 分析业务：QPS、数据量、一致性需求。2. 测试CAP表现：模拟分区故障。3. 混合架构：核心数据CP，缓存AP。示例：游戏排行用Redis（AP），交易用TiKV（CP）。最终，多数云数据库默认AP，业务补偿一致性。

FAQ

Q: CAP定理中P为什么不可避免？
A: 分布式系统依赖网络，网络故障、分区总是可能发生，必须容忍。

Q: 如何在云上实现CP数据库？
A: 选择TiDB、CockroachDB，支持分布式事务和Raft共识。

Q: AP系统的一致性怎么保证？
A: 通过最终一致性、读修复、反熵机制异步同步数据。

Q: 选型时优先哪个？
A: 视业务，金融选CP，日志/推荐选AP，大多场景AP更实用。