浅谈分布式一致性与CAP/BASE/ACID理论
https://www.cnblogs.com/zhang-qc/p/6783657.html
##转载请注明
CAP理论（98年秋提出，99年正式发表）：
- C（ Consistency）一致性：在分布式系统中，数据一致更新，所有数据变动都是同步的；
- A（ Availability）可用性：分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）；
- P（ Partition tolerance）分区容错性：分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。
- 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。
- 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据，分区容错性P满足，这在大多数系统中都会保证。但是一致性和可用性无法同时保证。多个节点上的数据可能是不一致的，如果保证强一致性，更新所有节点的数据项所用时间会增加，带来可用性问题。
- 一般来说跨区域的系统，设计师无法舍弃P性质，那么就只能在数据一致性和可用性上做一个艰难选择。三选二，怎么选择合理。其实三选二的公式具有一定误导性，三个指标按照程度来衡量，而不是有/没有。另外，分区并不是经常发生，那么在系统不存在分区的情况下有什么理由来牺牲C或者A。当分区存在或可感知其影响的情况下，就要预备一种策略去探知分区并显式处理其影响。这样的策略应分为三个步骤：探知分区发生，进入显式的分区模式以限制某些操作，启动恢复过程以恢复数据一致性并补偿分区期间发生的错误。
一致性C可依据程度分为：
- 强一致性（即时一致性）：所有的副本更新成功才返回；
- 弱一致性：不能保证即时，存在一个“不一致性窗口”；
- 最终一致性：是弱一致性的一种特例。经过一个不一致窗口然后到达一致状态。不一致窗口的大小可能依赖于这些因素：交互延迟、系统的负载、以及复制技术中副本的个数。几种方式可简单实现，比如增加update节点来以binlog方式更新，为防止单一节点失效，可以设置多个update节点，然后update节点将会以binlog更新所有节点。例如比特币系统，共识算法即采用的是最终一致性，为了保证其可用性。
A与C之间的选择引出了两种模型：BASE和ACID。
BASE的三个性质如下：
- Basically Available：基本可用，支持分区失败，例如sharding碎片划分数据库；
- Soft state：软状态，状态可以有一段时间不同步；
- Eventually consistent：最终一致性
- BASE采用的是弱一致性，来提升C与P上的保证。NoSQL运动的主题其实是创造各种可用性优先、数据一致性其次的方案。
ACID的四个性质如下：
- Atomicity（原子性）：一个事务中所有操作都必须全部完成，要么全部不完成。高层次的原子操作实际上可以简化分区的恢复；
- Consistency（一致性）：相比如CAP中的C更宽泛，指事务不能破坏任何数据库规则，要保持某些不变性约束，如键的唯一性；
- Isolation（隔离性）：事务将假定只有它自己在操作数据库，彼此不知晓；
- Durability（持久性）： 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
- 传统数据库采用这种强事务模型。
##转载请注明
CAP理论（98年秋提出，99年正式发表）：
- C（ Consistency）一致性：在分布式系统中，数据一致更新，所有数据变动都是同步的；
- A（ Availability）可用性：分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）；
- P（ Partition tolerance）分区容错性：分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。
- 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。
- 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据，分区容错性P满足，这在大多数系统中都会保证。但是一致性和可用性无法同时保证。多个节点上的数据可能是不一致的，如果保证强一致性，更新所有节点的数据项所用时间会增加，带来可用性问题。
- 一般来说跨区域的系统，设计师无法舍弃P性质，那么就只能在数据一致性和可用性上做一个艰难选择。三选二，怎么选择合理。其实三选二的公式具有一定误导性，三个指标按照程度来衡量，而不是有/没有。另外，分区并不是经常发生，那么在系统不存在分区的情况下有什么理由来牺牲C或者A。当分区存在或可感知其影响的情况下，就要预备一种策略去探知分区并显式处理其影响。这样的策略应分为三个步骤：探知分区发生，进入显式的分区模式以限制某些操作，启动恢复过程以恢复数据一致性并补偿分区期间发生的错误。
一致性C可依据程度分为：
- 强一致性（即时一致性）：所有的副本更新成功才返回；
- 弱一致性：不能保证即时，存在一个“不一致性窗口”；
- 最终一致性：是弱一致性的一种特例。经过一个不一致窗口然后到达一致状态。不一致窗口的大小可能依赖于这些因素：交互延迟、系统的负载、以及复制技术中副本的个数。几种方式可简单实现，比如增加update节点来以binlog方式更新，为防止单一节点失效，可以设置多个update节点，然后update节点将会以binlog更新所有节点。例如比特币系统，共识算法即采用的是最终一致性，为了保证其可用性。
A与C之间的选择引出了两种模型：BASE和ACID。
BASE的三个性质如下：
- Basically Available：基本可用，支持分区失败，例如sharding碎片划分数据库；
- Soft state：软状态，状态可以有一段时间不同步；
- Eventually consistent：最终一致性
- BASE采用的是弱一致性，来提升C与P上的保证。NoSQL运动的主题其实是创造各种可用性优先、数据一致性其次的方案。
ACID的四个性质如下：
- Atomicity（原子性）：一个事务中所有操作都必须全部完成，要么全部不完成。高层次的原子操作实际上可以简化分区的恢复；
- Consistency（一致性）：相比如CAP中的C更宽泛，指事务不能破坏任何数据库规则，要保持某些不变性约束，如键的唯一性；
- Isolation（隔离性）：事务将假定只有它自己在操作数据库，彼此不知晓；
- Durability（持久性）： 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
- 传统数据库采用这种强事务模型。