一致性算法原理

最新推荐文章于 2024-07-01 02:13:06 发布

现实社会!

最新推荐文章于 2024-07-01 02:13:06 发布

阅读量3.9k

点赞数 1

文章标签：算法 java 后端 zookeeper

本文链接：https://blog.csdn.net/l154491720/article/details/118104655

版权

一致性算法是为了解决分布式系统中的一致性问题，保证多节点间数据的同步。本文介绍了弱一致性、强一致性，并详细探讨了Paxos算法的不同版本，包括Basic Paxos和Multi-Paxos，以及Raft和Zookeeper的ZAB协议。这些算法在分布式系统中起着关键作用，确保数据的一致性和系统稳定性。

摘要由CSDN通过智能技术生成

一致性算法原理

一致性算法的出现是为了解决一致性问题，一致性问题是指对于一组服务器(集群)，给定一组操作，需要使用一种协议使得他们的结果最终达成一致，看起来好像是一台服务器一样。

弱一致性 (DNS)

DNS 就是典型的弱一致性，访问不同的 DNS 服务器可能在一开始不一致，但是等待一段时间后会一致。

强一致性 (主从同步)

Master 接受写请求
Master 复制日志至 slave
Master 等待，直到所有从库范围

问题：
一个节点失败，Master 阻塞，导致整个集群不可用，保证了一致性，可用性却大大降低。

强一致性 (多数派)

在并发环境下，无法保证系统正确性，顺序非常重要。

强一致性 - Paxos

Paxos 算法是莱斯利·兰伯特于 1990 年提出的一种基于消息传递的一致性算法且具有高度容错的一致性算法。这个算法被认为是类似算法中最有效的。

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

Paxos 算法有三种版本。下面我们一个一个来介绍。

Paxos
- Basic Paxos
- Multi Paxos
- Fast Paxos

Basic Paxos

在 Paxos 主要有3种角色 Proposer(提案者)、Acceptor(提议投票和接受者)、Learners(提议接受者)。外部角色 Client(请求发起者)。在具体实现种，一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor又是Learner。还有一个很重要的概念叫提案（Proposal）。最终要达成一致的value就在提案里。

角色介绍
- Client
  - 请求发起者，系统外部角色
- Proposer
  - 接收 client 请求，向集群提出提议。起到冲突调节的作用。
- Acceptor
  - 提议投票和接受者，只有在形成法定人数（Quorum）时，提议才会最终被接受。
- Learners
  - 提议接受者，备份，对集群一致性没有影响(不参与投票)
步骤和阶段
- Prepare
  - Proposer 提出一个议案，编号为N，此N大于这个 Proposer 之前提出的提案编号。请求 acceptors 的 quorum 接收。
- Promise
  - 如果N大于此 acceptor 之前接收的任何提案编号则接受，否则拒绝。
- Accept
  - 如果达到了多数派，Proposer 会发出 accept 请求。此请求包含提案编号N，以及内容。
- Accepted
  - 如果此 acceptor 在此期间没有收到任何大于 N 的提案，则接收此提案内容，否则忽略。

时序图如下:（成功的情况）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IRRhLObG-1624337364102)(一致性算法原理详解.assets/image-20210621142354500.png)]

只要 Accepted 达到多数派，则表示成功。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xnaJrSK6-1624337364104)(一致性算法原理详解.assets/image-20210621143952422.png)]

当第一次失败，或者第二次在第一次还未成功之前发送了有一次 prepare2 。那么会执行编号大的一次 prepare2 请求。比如在 Accept 期间，新的 proposer 发起 prepare2 请求。那么之前 prepare1 提案则将被拒绝。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KteERIDe-1624337364105)(一致性算法原理详解.assets/image-20210621144849870.png)]

这种情况成为活锁情况，当 prepare1 的提案还未被通过，然后出现 prepare2 提案，当 prepare2 提案未通过又出现 prepare3 .如此循环导致不断出现提案并且所有提案都未通过。举个例子，你和你女朋友去吃饭，她先提议说“吃火锅吧”。还没等她说完然后你说"我觉得烤鱼好一些"，然后她又说"昨天新开的一家海鲜排档还不错"。最后无尽的推翻前一次的提议。最后无法得到结论最后吃啥，导致产生活锁。