《架构师训练营》-第六周-NoSQL

介绍CAP、一致性协议、NoSQL数据库

CAP原理

一致性（Consistency）

Every read receives the most recent write or an error.
每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据，也就是说数据是一致的。

数据在多个副本之间是否能够保持一致的特性。

可用性（Availability）

Every request receives a(non-error) response,without the guarantee that it contains the most recent write.
每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入，也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。

系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

分区容错性（Partition tolerance）

The system continues to operate despite an arbitrary number of messages being dropped(or delayed) by the network between nodes.
即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的。

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非所有网络环境都发生了故障。

总结

对于分布式系统而言，分区容错性是前提，所以在保证分区容错性的情况下，一致性和可用性，只能二选一。

• 选择一致性：当发生网络失效的时候，系统可能返回一个错误码或者超时，即系统不可用
• 选择可用性：当发生网络失效的时候，系统总是可以返回一个数据，但是并不能保证这个数据是最新的。

ACID vs BASE

ACID

事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。事务具有原子性（Atomicity）,一致性（Consistency），隔离性（Isolation）和持久性（Durability）

BASE

BASE是Basically Available(基本可用)，Soft state(软状态)和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，但每个应用都可以根据自己的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用

基本可用是指分布式系统在出现不可预知的时候，允许损失部分可用性。例如：响应时间上的损失（原来响应时间0.5s,可能影响时间上升到1s-2s）；功能上的损失（降级页面）

软状态

允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，也就是允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性

系统中所有的副本在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实施保证系统的强一致性。

一致性协议

2PC

阶段一：提交事务请求

1.协调者向所有的参与者发送事务内容，等待各参与者的响应
2.各参与者执行事务，并将undo和redo进入事务日志中
3.如果参与者返回yes表示可以执行事务，如果返回no表示不可以执行事务

阶段二：执行事务提交

所有参与者都返回yes

1.协调者向所有参与者发出commit请求。
2.参与者收到commit请求后，正式提交事务并释放资源。
3.返回事务提交结果（ack）
4.协调者收到所有参与者的ack后，完成事务

存在参与者返回no

1.协调者向所有参与者发送rollback请求
2.参与者收到rollback消息后，根据undo信息来执行回滚。
3.返回事务回滚结果（ack）
4.协调者收到所有参与者的ack后，完成事务中断。

协调者异常

如果协调者没有完全发出commit就出现问题，则各个参与者的数据会出现不一致

3PC

阶段一：CanCommit

1.协调者向参与者发出包含事务内容的canCommit
2.参与者响应请求，认为可以执行返回yes，否则返回no

阶段二：PreCommit

所有都返回yes

1.协调者向所有参与者发送preCommit
2.参与者收到preCommit请求之后，则执行事务，并记录Undo和Redo
3.参与者返回ACK

存在no

1.协调者向所有参与者发送abort请求
2.参与者无论收到abort请求还是等待协调者请求超时，都会中断事务

阶段三：doCommit

全部返回yes

1.协调者向参与者发送doCommit请求
2.参与者收到请求后，正式执行事务提交操作
3.参与者向协调者发送ACK
4.协调者接收之后，事务结束

存在no或者超时

1.协调者向所有参与者发送abort请求
2.事务回滚

Paxos

ZAB

本文地址：https://blog.csdn.net/XiaMen_BuYu/article/details/107351575