分布式系统的设计基本原则-CAP理论

Consistency、Availability、Partition tolerance

1. Consistency：节点之间数据传递允许延时、阻塞、抛异常，但是必须实时准确。

   1. 如果数据更新后，并发访问下可立刻感知该更新成为强一致性。
   2. 如果允许部分或者全部感知不到该更新成为弱一致性。
   3. 若一段时间后，一定可以感知到更新称为最终一致性。

2. Availability：节点之间数据传递不允许超时或响应错误，但是可以返回假或者旧数据，要求有求必应。和一致性冲突。
3. Partition tolerance：某个节点挂掉不影响其它节点对外提供服务。

CAP理论

在一般的分布式系统中，P是必须保障的，C和A又存在矛盾，因此组合方式只能是CP或者AP。

上图表示CP和AP两种组合方式，node1、node2表示两个服务节点，x、y表示节点返回值。node1、node2之间的网线断掉了。

1. CP，无法满足可用性（MongDB、Redis、Hbase）

   该组合要求返回最值，客户端获取的x是旧数据，无法获取最新的y，有两种处理方式：

   1. 继续等待，直到超时或者无限等待。
   2. 抛出异常。

2. AP，无法满足一致性（Cassandra、CouchDB）

   client请求时，为了满足可用性node2必须尽快返回x，无法等待y做出响应，如果x是最新值这是没问题的,如果是旧值就违反了一致性。

一致性方案

1. Master-slave

   • RDBMS读写分离为典型Master-slave方案，Master响应写操作，slave响应读操作
   • 同步复制会保证强一致性但是影响可用性
   • 异步复制会保证可用性但是会降低一致性

2. WRN

   1. 主要用于去中心化（P2P )的分布式系统中。DynamoDB与Cassandra即采用此方案
   2. N代表副本数，W代表每次写操作要保证的最少写成功的副本数，R代表每次读至少读取的副本数
   3. 当W+R>N时 ,可保证每次读取的数据至少有一个副本具有最新的更新
   4. 多个写操作的顺序难以保证，可能导致多副本间的写操作顺序不一致，Dynamo通过向量时钟保证最终一致性

   假如有5个节点，每次写3个，那么每次至少读取3个才能满足W+R>N，显然这读取的3个里面至少有一个是最新数据。反证法，如果只读取2个，那么这两个节点有可能没有最新数据。如何判断最新数据？

   1. 版本号
   2. 时间戳

3. Paxos及其变种

   谷歌的chubby,Zookeeper的Zab（原子广播），RAFT

BASE方案

Basically Available（基本可用性）+Soft state（软状态）+Eventually consistent（最终一致性） 。

1. 基本可用性：分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如说用户查询数据的相应时间延长了，或者浏览高峰期时去掉很多非必须功能给用户相应一个简化版的页面。
2. 软状态:允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。
3. 最终一致性:所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。