Redis 哨兵模式和集群模式中的选主流程

2PC和3PC

一、Paxos 算法

Paxos 算法是一种分布式一致性算法,所谓的分布式一致性算法就是在分布式系统中,可以保证多个节点中数据的值是一致的的算法。

为什么需要一致性

  • 数据不能存在单个节点(主机)上,否则可能出现单点故障。
  • 多个节点(主机)需要保证具有相同的数据。
  • 一致性算法就是为了解决上面两个问题。

Paxos 是一种强一致性算法,又可以分为:

  • Basic Paxos
  • Multi-Paxos

1. 角色

在Paxos算法中,所有的参与者被分为了以下几个角色:

  • 提议者(proposer):提出提案,提案格式[编号Id,提议的Value]。Paxos算法需要我们手动保证提案的编号Id全局唯一有序。
  • 接受者(acceptor):接收提案,批准/拒绝提案,当提案被大多数的Acceptor(Quorum)批准后即为被选定的提案(Chosen)
  • 学习者 (learner):学习(Learn)最新被选定的提案

2. Basic Paxos算法

2.1 Basic Paxos算法过程

Basic Paxos 算法的决议过程分为两个阶段,Prepare阶段和Accept阶段:
basic paxos

Proposer需要发出两次请求,Prepare请求和Accept请求。Acceptor根据其收集的信息,接受或者拒绝提案。

(1)Prepare阶段

  • Proposer根据外部Client获得的提案编号N,发送Prepare(N)请求给超过半数(或更多)的Acceptor;
  • Acceptor收到消息后,如果Prepare请求中的N小于Acceptor之前处理过的提案的最大编号Y,那么不回复或者直接回复error
  • 如果Acceptor之前没有处理过请求,那么就回复接受以及当前的提案编号N
  • 如果N比Acceptor之前见过的最大编号Y还大,也回复接受,但是还要回复之前的编号Y及其内容[Y,VY],而且以后不会接受小于N的提案

(2)Accept阶段

  • 当Proposer收到超过半数的Prepare请求回复时,就可以发送Accept(N, V)请求了。 N就是自己的提案编号,V是Acceptor回复的最大提案编号对应的value,如果Acceptor没有回复任何提案,value就是Proposer自己的提案内容
  • Acceptor收到消息后,如果提案编号N大于等于之前见过的最大编号,就记录这个提案编号N和内容V,并回复接受请求。
  • 当Proposer收到超过半数的回复时,说明自己的提案已经被接受。否则回到第一步重新发起提案。
2.2 决议的发布
  • 一个显而易见的方法是当acceptors批准一个value时,将这个消息发送给所有learner。但是这个方法会导致消息量过大。
  • 可将accept消息发送给learners的一个子集,然后由这些learners去通知所有learners。
    但是由于消息传递的不确定性,可能会没有任何learner获得了决议批准的消息。当learners需要了解决议通过情况时,可以让一个proposer重新进行一次提案。

Learner 学习(获取)被选定的 value 有如下三种方案:
learn value

3. Multi-Paxos 算法

3.1 Basic Paxos 的活锁问题

如果有两个或多个Proposer依次提出编号递增的提案,会导致他们的提案都不能被接收,最终会陷入死循环。例如,见上图的1.2.b,Proposer1 接收到了半数以上的回复准备发起Accept(N,V)请求,但是这时候Proposer2又发起了N+1的提案,并且也接收到了半数以上的回复。这样Proposer1发起的Accept请求会遭到拒绝,因为Proposer2的提案使得Acceptor不再处理小于N+1的请求了。然后Proposer1又发起N+2的提案又导致Proposer2的提案不能处理,就这样最终形成活锁(LiveLock)问题

那么如果解决活锁问题来保证Paxos算法的活性呢?解决方案是提案被拒绝后给一个随机的等待时间,再重新发起提案,这样就减少同时请求的可能。

活性:
保证最终有一个提案会被选定,当提案被选定后,进程最终最终也能获取到被选定的提案。
安全性:
提案(value)只有在被 proposers 提出后才能被批准。
在一次 Paxos 算法的执行实例中,只批准(chosen)一个 value。
learners 只能获得被批准(chosen)的 value。

当然,活锁问题也可以使用Multi-Paxos算法来解决。它会从Proposer中选出一个Leader,只由Leader提交Proposal,还可以省去Prepare阶段,减少了性能损失。

3.2 Multi-Paxos 算法过程

(1)首先(通过Base Paxos算法)从多个Proposer中选择一个节点成为Leader;
(2)这是就不用再经过Prepare阶段了。Leader可以直接向Acceptor中的半数以上发起提案Accept请求;
(3)如果Leader接收到半数以上的Acceptor的接受回复,那么就表示这个提供通过。

multi-paxos
注意这里提案内容中相比Basic Paxos,新增了一个类似请求轮数的参数 I,Leader每次(向多数Acceptor)发起一次提案,这个 I 的值都要加1。

二、Raft 算法

Raft算法是Paxos算法的一种简化实现。Raft 算法动画演示。基本流程主要分为3个部分:

  • 选主过程(leader election)
  • 日志复制(log replication)
  • 安全性(safety)加上成员变更(membership changing)

1. 角色

  • Leader(领袖):leader负责日志复制的过程。并且将自己的日志通过心跳发送给其他机器同步日志,所有来自客户端的写请求都会由leader处理,在过半数的机器提交之后就可以返回成功标志给客户端
  • Candidate(候选人):当Leader宕机时,超过超时时间未收到心跳包的Follower会转变成Candidate,Candidater会向集群内的所有机器发送请求投票给自己的请求。选举出Leader之后又会退化成Follower。
  • Follower(群众):所有节点在初始化之后,还没有选举出Leader之前都是Follower。Follower的职责仅仅是接受来自Leader的复制日志的请求,或是在Leader宕机时(未在超时时间内接受到心跳信息)变成Candidate,然后尝试成为leader。亦或是接受到Candidate的投票请求时响应请求。

roles

此外,Raft 算法中还有一个任期(Term)的概念。

2. 领导选举过程

(1)处于Follower状态的节点在一个随机的超时时间(称之为Election timeout,注意每次都要随机选择一个超时时间,这个超时时间通常为150-300毫秒,通常设置的是300+ms)内没有收到投票或者日志复制和心跳包的RPC,则会变成Candidate状态。
(2)处于Candidate状态的节点会马上开始选举投票。它先投自己一票,然后向其他节点发送投票,这个请求称之为Request Vote RPC。如果获得了过半的节点投票,则转成Leader状态。如果投票给了其他节点或者发现了更新任期(Term)的指令(如更新任期的选举投票和日志复制指令),则转为Follower状态。如果选举超时没有得到过半投票,则保持Candidate状态开始一个新一轮选举投票。
(3)处于Leader状态的节点会定期发送(这个时间为HeartbeatTimeout,通常要远小于选举超时,通常设置的位50ms)AppendEntries RPC请求给其他节点。如果发现了更新任期的指令,则自己也转为Follower状态

选举投票需要两个条件:

  • 条件一:请求投票的节点的任期必须大于等于本节点且本节点还没有投过票给其他节点(包括投票给自己)。
  • 条件二:请求投票的节点的日志必须是包含了最新提交日志的节点,这是为了保证日志安全增加的限制条件。如何保证请求投票节点包含了最新提交日志呢?可以比较两个节点最后一条日志的任期,如果任期不一样,则任期大的日志更新;如果任期一样,则日志更长的更新。

3. 日志复制过程

https://www.cnblogs.com/cbkj-xd/p/12152222.html

## 三、哨兵模式的选主流程

## 四、集群模式的选主流程


参考:

  • https://www.jianshu.com/p/1f5cb602dc71
  • https://juejin.cn/post/6844904046139179015
  • https://juejin.cn/post/6899464146719342605
  • https://blog.csdn.net/paincupid/article/details/78058087
  • https://blog.csdn.net/u013970991/article/details/76602213
  • https://juejin.cn/post/6844903621499305997#heading-3
  • https://juejin.cn/post/6844904017777295368#heading-1
  • https://juejin.cn/post/6844904066854682638
  • https://juejin.cn/post/6844903834611875848
  • https://juejin.cn/post/6844904118184574983
  • https://juejin.cn/post/6907151199141625870
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值