分布式架构设计中的CAP原理

分布式架构设计中的CAP原理

[toc]

参考：分布式系统的思考及CAP理论

总结

CAP原则又称CAP定理，指的是在一个分布式系统中：

• Consistency（一致性）：每次读操作都能保证返回的是最新数据；

• Availability（可用性）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果；
  备注：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），换句话就是说，任何时候，任何应用程序都可以读写数据。

• Partition tolerance（分区容错性）：以当节点间出现网络分区，照样可以提供服务。

CAP理论指出：CAP三者只能取其二，不可兼得。

CAP原则

详情

一、单实例

单机系统和显然，只能保证CP，牺牲了可用性A。单机版的MySQL，Redis，MongoDB等数据库都是这种模式。

单实例

二、多副本

image

相比于单实例，这里多了一个节点去备份数据。

对于读操作来说：因为可以访问两个节点中的任意一个，所以可用性提升。
对于写操作来说：根据更新策略分为三种情况：
1.同步更新：即写操作需要等待两个节点都更新成功才返回。这样的话如果一旦发生网络分区故障，写操作便不可用，牺牲了A。

2.异步更新：即写操作直接返回，不需要等待节点更新成功，节点异步地去更新数据（FastDFS文件系统的存储节点就是用这种方式，写完一份数据之后立即返回结果，副本数据由同步线程写入其他同group的节点）。这种方式，牺牲了C来保证A，即无法保证数据是否更新成功，还有可能会由于网络故障等原因，导致数据不一致。

3.折衷：更新部分节点成功后便返回。例如Kafka、
其实，折衷方案和异步更新的方式从本质上来说是一样的，都是损失一定的C来换取A的提高。而且，会产生'脑裂'的问题--即网络分区时节点各自处理请求，无法同步数据，当网络恢复时，导致不一致。

三、分片
基于分片解决了数据量大的问题，由于所有数据只有一份，一致性得以保证；节点间不需要通信，分区容忍性也有。
然而，当任意一个节点挂掉，丢失了一部分的数据，系统可用性得不到保证。

分片

四、集群

image

image

可以看到，上面这种方式综合了前两种方式。同上分析，采用不同的数据同步策略，系统CAP保证各有不同。不过，一般数据库系统都会提供可选的配置，我们根据不同的场景选择不同的特性。