【Raft】分布式一致性算法Raft和zab、paxos

下图：各个节点的同步情况，实际上4节点目前远远落后于其他节点，而1-3-5节点的前7次log已经完成提交了，因为得到了超过半数节点的确认。（讲解：raft internal vs zab---https://www.bilibili.com/video/BV1Zz411i7Rr?from=search&seid=674793516552630434）

Raft手动设置模拟

主页：

peng-xin/raftscope: super hacky visualization of Raft --https://github.com/peng-xin/raftscope

用git命令下载下面的web项目后，直接点击打开index.html

git clone https://github.com/peng-xin/raftscope.git

使用方法见教程：动画演示 raft 在脑裂发生之后仍然可以正常工作吗？_https://www.bilibili.com/video/BV1Fi4y147ad?from=search&seid=8328232223355833905

Raft协议说明

多个节点的一致性

node有三个状态follower,candidate,leader，开始状态为follower，follower没有收到leader信息时可以变成candidate状态，candidate会发送投票给其他节点，其他节点返回相应，会变成leader状态，这个过程称为Leader选举。
所有的修改都是通过leader进行，当leader接收到修改的内容时，会作为Entry存储在log中，现在处于uncommit状态，leader发送给其他节点这个改变，只要多于一般的节点回复了，leader节点就更改本身设置的值，提交commit命令修改状态，这个过程称为日志复制。

Leader选举

leader选举有两个超时，一个选举超时，选举超时随机设置150-300ms，超时后，follower会变成candidate状态，发送请求投票给其他节点，其他节点没有发送请求投票就会投同意票，同时重置选举超时时间，candidate节点获得过半数票就会成为leader节点。leader会发送Append Entries消息给其他follower，消息发送在心跳超时前，follower会回复消息，这种情况会保持到follower停止接收心跳消息变成candidate结束。停止leader节点后，follower等待选举超时会变成candidate请求成为leader节点。过半的原则能够保证集群中有一个leader，如果多个节点同时获取相同选票，那么进入新一轮选举。

Log复制

客户端发送更改请求到leader，leader会添加到日志中，下一个心跳会发送给其他follower，过半节点应答了，leader会committed这个更改，同时回复给客户端。当有网络隔离造成集群分隔成两个集群时，会生成两个leader，分别接受更改的请求，但是由于需要过半同意才会提交更改，所以集群节点不过半的小集群没办法更改结果。如果这时候网络隔离消失了，集群节点通了，两个leader中term低的会自动停下，未提交的更改会回退回去，同步新的leader日志。
疑问？如果term低的是个大集群，然后提交了更改，然后网络通了，term低的leader停下，同步新leader的数据，原来提交的数据会同步过去吗？

链接：https://www.jianshu.com/p/5b59869d6273

Raft和zab区别

共同点：

都是共识算法，写数据时都需要大部分成功才能把日志应用到状态机。
都有选主、日志对齐、数据广播的流程。
都把数据分成快照+日志。

都使用timeout来重新选择leader.
采用quorum（法定人数）来确定整个系统的一致性(也就是对某一个值的认可),这个quorum一般实现是集群中半数以上的服务器,zookeeper里还提供了带权重的quorum实现.
都由leader来发起写操作.
都采用心跳检测存活性。
zookeeper的zab实现里选主要求选出来的主拥有quorum里最新的历史，而raft的follower的选主投票根据term的大小+日志完成度来选择投票给谁，这点上来看是比较类似的。

链接：https://www.zhihu.com/question/28242561/answer/40075530

不同点：

zab用的是epoch（时代; 纪元）和count的组合来唯一表示一个值, 而raft用的是term和index。
raft协议数据只有单向地从leader到follower(成为leader的条件之一就是拥有最新的log), 而zab的zookeeper实现中，一个prospective leader需要将自己的log更新为quorum里面最新的log,然后才好在synchronization阶段将quorum里的其他机器的log都同步到一致.（prospective ：有望的; 可能的; 预期的; 潜在的）

BTW, raft实现起来比zab会简单很多.
链接：https://www.zhihu.com/question/28242561/answer/40075530

ZAB协议好像本身并没有实现配置变更的算法，而在raft论文中是明确提出相关算法的。这并不是说ZAB协议就不能实现，只能说原生的ZAB协议没有说明这一点。（凭印象）这也导致了ZooKeeper直到最近一两年才释出稳定版的可以支持动态配置更新的版本3.5。

paxos算法----编辑中

白话讲解paxos&raft算法原理及实战_https://www.bilibili.com/video/BV19t411c75p?p=2

Paxos算法详解_https://blog.csdn.net/omnispace/article/details/79653932?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2.control

Paxos算法解决的问题正是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。

Paxos算法背景

Paxos算法是一种基于消息传递的分布式一致性算法。

Paxos算法流程

Paxos算法运行在允许宕机故障的异步系统中，不要求可靠的消息传递，可容忍消息丢失、延迟、乱序以及重复。它利用大多数 (Majority) 机制保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障。

一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)，Paxos算法使所有提案中的某一个提案，在所有进程中达成一致。系统中的多数派同时认可该提案，即达成了一致。最多只针对一个确定的提案达成一致。

Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner):

Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。
Acceptor：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。
Learner：不参与决策，从Proposers/Acceptors学习最新达成一致的提案（Value）。

在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色。

Neat Algorithms - Paxos -http://harry.me/blog/2014/12/27/neat-algorithms-paxos/

这篇文章里面有用JS写的Paxos过程，有助理解。但是没怎么仔细看，没时间。

这篇文章用两军问题来讨论Paxos，也很有意思：

http://iunknown.iteye.com/blog/2246484

在计算机通信理论中，有一个著名的两军问题(two-army problem)，讲述通信的双方通过ACK来达成共识，永远会有一个在途的ACK需要进行确认，因此无法达成共识。

（注意：两军问题是无解的。Paxos只是达成共识，涉及ack和行动，仍然是无解）

【转载】两军问题与Paxos算法 & 动画讲解Paxos算法 - https://www.cnblogs.com/charlesblc/p/6037963.html

复习

什么是Raft？能简单说一下它的工作流程吗

Raft 是一种为了管理复制日志的一致性算法，旨在替代 Paxos，使其在实际应用中更容易理解和实现。Raft 通过强领导者模型、任期以及心跳机制等特性简化了分布式系统中达成一致性的过程。它被设计为可理解性强、易于实现，并且能够提供与 Paxos 相同的容错保证。

Raft 工作流程简述

领导者选举（Leader Election）:
- Raft 将时间划分为任意长度的任期（term），每个任期开始于一次选举。如果一个候选者赢得了选举，则它将成为该任期的领导者。
- 如果服务器启动或当前领导者失效，跟随者（follower）会转变为候选者（candidate），增加自己的任期号，并请求其他服务器为其投票。
- 得到大多数选票的候选者将成为新的领导者，并开始向所有跟随者发送心跳消息以维持其领导地位。
日志复制（Log Replication）:
- 领导者接收来自客户端的请求，并将这些请求作为新条目附加到其日志中，然后并行地向其他服务器复制这条日志条目。
- 当跟随者成功复制了一个日志条目后，它会应用这个更新到自己的状态机。
- 领导者只有在大多数服务器确认了日志条目之后，才会将该条目提交，并通知跟随者们可以安全地应用此条目。
安全性（Safety）:
- Raft 确保每个任期内的领导者都是唯一的，而且一旦一个日志条目已经被提交，就不会有其他日志条目覆盖它。
- 例如，在领导者选举期间，候选者必须拥有包含所有已提交日志条目的日志才能赢得选举，这确保了领导者总是具有最新的已提交日志。

通过这种方式，Raft 能够确保即使部分节点出现故障，整个系统仍然能够保持一致性和可用性。这种一致性算法广泛应用于构建高可用性的分布式系统和服务中。

选出领导者之后客户端怎么知道哪个节点上领导者？

在 Raft 算法中，客户端需要知道哪个节点是当前的领导者以便直接向其发送请求，这样可以减少不必要的延迟和复杂性。以下是几种常见的机制来让客户端得知当前的领导者：

重定向机制：
- 当客户端向非领导者节点发送请求时，这个节点会检查它是否是当前的领导者。如果不是，该节点将拒绝请求，并告知客户端真正的领导者地址（通过返回一个特殊的错误响应，包含领导者的网络地址）。
- 客户端收到这样的响应后，就会向指定的领导者节点重新发起请求。
心跳消息：
- 领导者定期向所有跟随者节点发送心跳消息以维持其权威性。跟随者可以通过这些心跳消息保持对当前领导者的了解。
- 虽然这不是直接通知客户端的方式，但一些实现可能会让跟随者节点缓存最新的领导者信息，并在接收到客户端请求时提供这一信息。
服务发现或负载均衡器：
- 在某些部署场景下，可以使用外部的服务发现系统或者负载均衡器来追踪当前的领导者，并指导客户端直接连接到正确的节点。
- 这种方式通常用于更复杂的架构中，其中可能包括自动化的故障转移处理和其他高级特性。
客户端主动查询：
- 某些情况下，客户端可能会周期性地询问集群中的任意成员关于当前领导者的身份。这种方法虽然简单，但在频繁变动的环境中可能导致较高的开销。