分布式理论——CAP定理

CAP定理:对于一个分布式计算系统来说，不可能同时满足以下三点

• 一致性（Consistency）:所有节点访问时都是同一份最新的数据副本
  PS:客户端在数据写入任何一台服务器并成功响应后，之后的客户端从其他服务器读取到的都是刚写入的数据
• 可用性（Availability）:每次请求都能获取到非错的响应，但是不能保证数据最新
  PS非故障节点收到请求后必须要有相应的响应给客户端
• 分区容错性（Partition tolerance）:遇到网络分区故障时，仍能对外提供满足一致性和可用性服务，除非整个网络环境都发生了故障
  PS:如下图G1和G2可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。
  
  论证为什么不能同时满足：假设存在三者全满足的系统，以上图为例，client向G1服务器写入一个v0=1的数据，因为满足分区容错性原则，即可能因某些原因导致G1、G2不能同步，所以client在读取数据时，由于要满足可用性原则所以一定要返回数据，G1返回v0=1，G2返回v0=0，两者不一致，不满足一致性原则，即 !C A P

CAP三者如何权衡

• CA (Consistency + Availability)：对一致性非常严格，系统不能容忍网络错误或节点错误，一旦出现错误，整个系统就会拒绝写请求
• CP (consistency + partition tolerance)：它关注的是系统里大多数的一致性协议。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性
• AP (availability + partition tolerance)：这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本

如何进行三选二

放弃了一致性，满足分区容错，那么节点之间就有可能失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会容易导致全局数据不一致性。对于互联网应用来说，机器数量庞大，节点分散，网络故障再正常不过了，那么此时就是保障AP，放弃C的场景，而从实际中理解，像网站这种偶尔没有一致性是能接受的，但不能访问问题就非常大了
如：淘宝、京东、苏宁易购等网站
对于银行来说，就是必须保证强一致性，也就是说C必须存在，那么就只用CA和CP两种情况，当保障强一致性和可用性（CA），那么一旦出现通信故障，系统将完全不可用。另一方面，如果保障了强一致性和分区容错（CP），那么就具备了部分可用性。实际究竟应该选择什么，是需要通过业务场景进行权衡的（并不是所有情况都是CP好于CA，只能查看信息但不能更新信息有时候还不如直接拒绝服务）

CAP——————BASE理论

既然无法同时满足CAP，所以出现了BASE理论：
BASE：Basically Available（基本可用），Soft state（软状态）, Eventually consistent（最终一致性） 三个短语的缩写 ,Base 理论是对 CAP 中一致性和可用性权衡的结果，其核心思想是： 既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

• Basically Available(基本可用)
  假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
  响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒返回结果。
  功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面（如双十一期间的-------哎呀，服务器被挤爆啦，请稍后再试）
• Soft state（软状态）
  相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
  软状态指的是：允许系统中的数据存在中间状态，并认为该状态不会影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
• Eventually consistent（最终一致性）
  上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。