分布式一致性

分布式一致性

分布式一致性是指在分布式环境中对某个副本数据进行更新操作时，必须确保其他副本也会更新，避免不同副本数据不一致。
分布式系统一个重要的问题时解决数据复制,一是为了增加系统的可用性防止单点故障，二是提高系统可用性，通过负载聚恒，使分布在不同位置的数据副本能够提供服务。

一致性级别

理想状态下，当然希望分布式系统能够实现数据一致性并且让各个方面都满足要求，但这是难以达到的，例如如果在更新数据时通过将其他动作阻塞只进行写入操作，若写入涉及大量操作且耗时那么必然影响系统的整体可用性。因此，对于分布式一致性会分为不同的级别，以适应不同的环境。

强一致性

写入与读取数据一致，性能最弱。

弱一致性

写入成功后，不能立即读取到最新的数据，也不保证多久能达到一致。
弱一致性又分为会话一致性和用户一致性。
会话一致性只保证写入值在通过会话客户端读取到一致的值。
用户一致性值保证写入的值同个用户能立即读取到。

最终一致性

数据不保证一致性，只能确保会在一定时间内达到数据一致性的状态。

分布式一致性协议

在分布式系统中有些事务操作需要跨越节点，为保持事务的一致性，需要协调的组件进行调度，并决定是否将事务进行提交，因此提交的策略也分为二阶段提交和三阶段提交。

2PC

二阶段提交是分布式架构下节点进行事务处理时，为保持原子性和一致性而制定的算法。

阶段一:

1.事务询问（协调者向参与者发送事务内容）
2.执行事务(各节点执行事务操作，将Undo和Redo写入事务日志)
3.各节点向协调者反馈事务询问（节点执行成功则反馈YES，表示事务可执行，失败则为NO）

阶段二:

阶段二协调者会根据各节点反馈情况决定是否进行事务提交。
1.发送提交请求(向各节点发出Commit请求)
2.事务提交(节点接收Commit请求后执行事务操作，提交并释放资源)
3.反馈事务提交结果
4.完成事务(协调者接收到所有节点反馈后，完成事务)

如果节点向协调者反馈No，或等待超时，协调者没有接收到所有节点的反馈响应则中断事务。

中断事务过程:
1.发送回滚请求
2.事务回滚(节点接收Rollback请求之后 ，利用Undo执行回滚并释放资源)
3.反馈事务回滚结果
4.中断事务

以上时二阶段提交的过程处理逻辑。分为事务提交和事务中断。图示如下:

优缺点:
原理简单，实现方便(优点)
同步阻塞，单点问题，脑裂，太保守(缺点)

三阶段提交

三阶段提交将二阶段提交事务过程分为两个阶段。

阶段一:提交

1.事务询问
2.各节点反馈事务询问的响应