当前位置:   article > 正文

目前最详细、最常见的一致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR_一致性算法有哪些

一致性算法有哪些

背景

在常见的分布式系统中,总会发生诸如机器宕机或网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等情况。

一致性算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,并且保证不论发生以上任何异常,都不会破坏整个系统的一致性。

 

CAP 定理

CAP 理论告诉我们,一个分布式系统不可能同时满足一致性(C:Consistency),可用性(A: Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中的2个。

选项

描述

C(Consistence)

一致性,指数据在多个副本之间能够保持一致的特性(严格的一致性)。

A(Availability)

可用性,指系统提供的服务必须一直处于可用的状态,每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。

P(Network partitioning

分区容忍性,分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。

 

分析结果

CA

满足原子和可用,放弃分区容错。说白了,就是一个整体的应用。

CP

满足原子和分区容错,也就是说,要放弃可用。当系统被分区,为了保证原子性,必须放弃可用性,让服务停用。

AP

满足可用性和分区容错,当出现分区,同时为了保证可用性,必须让节点继续对外服务,这样必然导致失去原子性。

 

Base 理论

BASE:全称:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)。

Base 理论是对 CAP 中一致性和可用性权衡的结果,其来源于对大型互联网分布式实践的总结,是基于 CAP 定理逐步演化而来的。其核心思想是:既是无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

 

解释一下:什么是软状态呢?相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种 “硬状态”。软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。

 

2PC

Two-Phase Commit,事务的提交过程分成了两个阶段来进行处理。

 

2PC 阶段一

1. 事务询问

协调者向所有的参与者询问,是否准备好了执行事务,并开始等待各参与者的响应。

2. 执行事务

各参与者节点执行事务操作,并将 Undo 和 Redo 信息记入事务日志中

3. 各参与者向协调者反馈事务询问的响应

如果参与者成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行;如果参与者没有成功执行事务,就返回 No 给协调者,表示事务不可以执行。

 

2PC 阶段二

在阶段二中,会根据阶段一的投票结果执行 2 种操作:执行事务提交,中断事务。

执行事务提交步骤如下:

  1. 发送提交请求:协调者向所有参与者发出 commit 请求。
  2. 事务提交:参与者收到 commit 请求后,会正式执行事务提交操作,并在完成提交之后释放整个事务执行期间占用的事务资源。
  3. 反馈事务提交结果:参与者在完成事务提交之后,向协调者发送 Ack 信息。
  4. 协调者接收到所有参与者反馈的 Ack 信息后,完成事务。

中断事务步骤如下:

  1. 发送回滚请求:协调者向所有参与者发出 Rollback 请求。
  2. 事务回滚:参与者接收到 Rollback 请求后,会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源。
  3. 反馈事务回滚结果:参与者在完成事务回滚之后,想协调者发送 Ack 信息。
  4. 中断事务:协调者接收到所有参与者反馈的 Ack 信息后,完成事务中断。

从上面的逻辑可以看出,二阶段提交就做了2个事情:投票,执行。

例子

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/311665
推荐阅读
相关标签