分布式之 CAP 原则

---

CAP理论是分布式系统的基石,值得我们深入理解。这里举几个典型的例子来加深理解:

1. CA模式:传统的主从复制模式。主节点负责处理所有写请求,从节点同步主节点数据,保证一致性。但一旦主节点不可用,整个系统也不可用,无法容忍网络分区。典型实现为MySQL主从模式。
2. CP模式:采用分布式锁机制的系统。在访问共享资源前,所有节点首先需要获锁,保证同一时间只有一个节点在操作数据,实现强一致性。但无法实现高可用性,一旦锁节点失效会影响整体系统。典型如Zookeeper。
3. AP模式:许多NoSQL数据库采用最终一致模型来实现高可用性。更新可以在任何副本执行,然后异步复制到其他节点。在分区期间,各分区内部仍旧可以访问到最新数据,实现高可用性。但数据在分区恢复之前不一致,为最终一致。如DynamoDB、Cassandra等。
4. CP并行执行:一种实现CP而不影响可用性的模式。在访问共享资源前,节点需要共同达成一致(如选主节点),但更新执行可以并行在各个节点上进行,然后再进行同步。如果更新执行时间足够短,可以实现CAP,但这需要对系统时延有较高要求。
5. AP最终一致:更新在任意副本执行,所有的写操作都会收到成功响应。然后节点间通过异步复制同步数据,在一定时间内实现最终一致。系统可用性以及分区容忍性更高,但会出现一定时间内的信息不一致。如Cassandra、Dynamo等系统的一致性策略。
6. 多数据模式:将数据分为关键数据与非关键数据。对关键数据采用CP模式来实现强一致性,对非关键数据采用AP模式来实现高可用性。这样可以平衡系统整体的CAP属性。如可将用户账户信息作为关键数据,浏览历史作为非关键数据。
   综上,不同的Consistency、Availability与Partition Tolerance取舍会产生不同的系统行为与数据特性。实际系统 Often需要根据业务选择恰当的模式或模式组合来满足需求。这需要对CAP有充分理解,权衡系统对不同属性的依赖程度来进行取舍。

CAP定义

Consistency 一致性: 所有节点在同一时间的数据完全一致.一致性可以分为以下三种:
强一致性: 更新操作后,后续操作一定取到的是更新后的结果
弱一致性: 更新操作后,后续操作可以容忍部分或全部没有更新
最终一致性: 更新操作后,在一段时间后要求能够取到更新后的结果
Availability 可用性: 服务在正常响应时间内一致可用
Partition Tolerance 分区容错性: 分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务

应用场景

CA without P 放弃系统扩展性,不部署子节点,比如单节点的关系型数据库
CP without A 在分布式服务器中保持强一致性,但可能会导致同步时间长,比如分布式数据库 redis
AP without C 放弃一致性,保持高可用.每个节点使用本地数据提供服务.使得全局数据不一致.比如使用手机网购,可能浏览商品时还有货,但下单时系统告诉你下单失败.

如有错误欢迎指正