分布式CAP原理以及如何取舍

CAP理论

什么是分布式系统

部分在不同的节点上，通过网络协同工作的系统叫做分布式系统

CAP分别代表什么

• 一致性： 更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致
• 可用性:     读和写操作都能成功
• 分区容错性：再出现网络故障导致分布式节点间不能通信时，系统能否继续服务​​​​​​​

CAP的是什么关系 

在分布式系统的设计中，没有一种设计可以同时满足一致性，可用性，分区容错性 3个特性

注意：不要将弱一致性，最终一致性放到CAP理论里混为一谈

弱一致性，最终一致性 你可以认为和CAP的C一点关系也没有，因为CAP的C是更新操作完成后，任何节点看到的数据完全一致, 弱一致性。最终一致性本身和CAP的C一致性是违背的，

为什么会3选2

我们来看一个简单的问题, 一个DB服务   搭建在两个机房（北京,广州)，两个DB实例同时提供写入和读取

  1. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功
      在没有出现网络故障的时候，满足CA原则，C 即我的任何一个写入，更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致， A 即我的读写操作都能够成功，但是当出现网络故障时，我不能同时保证CA，即P条件无法满足
  2. 假设DB的更新操作是只写本地机房成功就返回，通过binlog/oplog回放方式同步至侧边机房
      这种操作保证了在出现网络故障时,双边机房都是可以提供服务的，且读写操作都能成功，意味着他满足了AP ，但是它不满足C，因为更新操作返回成功后，双边机房的DB看到的数据会存在短暂不一致，且在网络故障时，不一致的时间差会很大（仅能保证最终一致性）
  3. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务
      降级服务，如停止写入，只提供读取功能，这样能保证数据是一致的，且网络故障时能提供服务，满足CP原则，但是他无法满足可用性原则

选择权衡

通过上面的例子，我们得知，我们永远无法同时得到CAP这3个特性，那么我们怎么来权衡选择呢？
选择的关键点取决于业务场景

对于大多数互联网应用来说（如网易门户），因为机器数量庞大，部署节点分散，网络故障是常态，可用性是必须需要保证的，所以只有设置一致性来保证服务的AP，通常常见的高可用服务吹嘘5个9 6个9服务SLA稳定性就本都是放弃C选择AP，比如淘宝双11，用户可以正常浏览，下单为可用性，统计用户浏览页面次数，或者购买总额分析需要一致性，那么淘宝必定先保证用户能够正常下单，后面再考虑分析用户数据。毕竟如果都不能正常进行交易还分析个什么呢。

对于需要确保强一致性的场景，如银行，通常会权衡CA和CP模型，CA模型网络故障时完全不可用，CP模型具备部分可用性，实际的选择需要通过业务场景来权衡（并不是所有情况CP都好于CA，只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务）

BASE(Basically Available, Soft State, Eventual Consistency  基本可用、软状态、最终一致性) 对CAP AP理论的延伸, Redis等众多系统构建与这个理论之上
ACID  传统数据库常用的设计理念, ACID和BASE代表了两种截然相反的设计哲学，分处一致性-可用性分布图谱的两极。

 

参考​​​​​​​