RocketMQ 多副本前置篇:初探raft协议

目录

  • 1、Leader选举

    • 1.1 一轮投票中,只有一个节点发起投票的情况
    • 1.2 一轮投票中,超过一个节点发起投票的情况
    • 1.3 思考如何实现Raft选主
  • 2、日志复制

Raft协议是分布式领域解决一致性的又一著名协议,主要包含Leader选举、日志复制两个部分。

温馨提示:
本文根据raft官方给出的raft动画进行学习,其动画展示地址:http://thesecretlivesofdata.com/raft/

@(本节目录)

1、Leader选举

1.1 一轮投票中,只有一个节点发起投票的情况


Raft协议中节点有3种状态(角色):

  • Follower
    跟随者。
  • Candidate
    候选者。
  • Leader
    领导者(Leader),通常我们所说的的主节点。

首先3个节点初始状态为 Follower,每个节点会有一个超时时间(计时器),其时间设置为150ms~300ms之间的随机值。当计时器到期后,节点状态从 Follower 变成 Candidate,如下图所示:

通常情况下,三个节点中会有一个节点的计时器率先到期,节点状态变为 Candidate ,候选者状态下的节点会发起选举投票。我们先来考虑只有一个节点变为Candidate时是如何进行选主的。

当节点状态为Candidate,将发起一轮投票,由于是第一轮投票,设置本轮投票轮次为1,并首先为自己投上一票,正如上图所示的NodeA节点,Team为1,Vote Count为1.

当一个节点的定时器超时后,首先为自己投上一票,然后向该组内其他的节点发起投票(用拉票更加合适),发送投票请求。

当集群内的节点收到投票请求外,如果本轮未进行过投票,则赞同,否则反对,然后将结果返回,并重置计时器。

当节点A收到的赞同票大于一半时,则升级为该集群的 Leader,然后定时向集群内的其他节点发送心跳,以便确定自己的领导地位,正如下图所示。

Node A,集群中的 Leader正在向其他节点发送心跳包。

节点在收到 Leader 的心跳包后,返回响应结果,并重置自身的计时器,如果 Flower 状态的节点在计时时间超时内没有收到Leader 的心跳包,就会从 Flower 节点变成 Candidate,该节点就会发起下一轮投票。

例如NodeA节点宕机,停止向它的从发送心跳,我们来看一下集群如何重新选主。

如果主节点宕机,则停止向集群内的节点发送心跳包。随着计时器的到期,节点B的先于节点C变成 Candidate,则节点B向集群内的其他节点发起投票,如下图所示。

节点B,首先将投票轮次设置为2,然后首先为自己投上一篇,然后向其他节点发起投票请求。

节点C收到请求,由于其投票轮次大于自己的投票轮次,并该轮次并未投票,投出赞成票并返回结果,然后重置计时器。节点B将顺理成章的成为新的Leader并定时发送心跳包。

3个节点的选主就介绍到这里了,也许有网友会说,虽然各个节点的计时器是随机的,但也有可能同一时间,或一个节点在未收到另一个节点发起的投票请求之前变成 Candidate,即在一轮投票过程中,有大于1个的节点状态都是 Candidate,那该如何选主呢?

下面以4个节点的集群为例,来阐述上述这种情况情况下,如何进行选主。

1.2 一轮投票中,超过一个节点发起投票的情况

首先同时有两个节点进入Candidate状态,并开始新的一轮投票,当前投票编号为4,首先先为自己投上一票,然后向集群中的其他节点发起投票,如下图所示:

然后各个节点收到投票请求,如下所示,进行投票:

首先节点C、D在收到D、C节点的投票请求时,都会返回不同意,因为在本轮投票中,已经各自为自己投了一票,按照上图,节点A同意C节点、节点B同意D节点,那此时C、D都只获的两票,当然如果A,B都认为C或D成为主节点,则选择就可以结束了,上图显示,C、D都只获的2票,未超过半数,无法成为主节点,那接下来会发生什么呢?请看下图:

此时A,B,C,D的定时器各自在倒计时,当节点成为Candidate时,或自身状态本身是Candidate并且定时器触发后,发起一轮新的投票,图中是节点B、节点D同时发起了新的一轮投票。

投票结果如下:节点A,节点C同意节点B成为leader,但由于BD都发起了第5轮投票,最终的投票轮次更新为6,如图所示:

关于Raft协议的选主就介绍到这里了,接下来我们来思考一下,如果自己实现 Raf t协议,至少要考虑哪些问题,为下一篇源码阅读Dleger(RocketMQ多副本)模块提供一些思路。

1.3 思考如何实现Raft选主

  1. 节点状态
    需要引入3中节点状态:Follower(跟随者)、Candidate(候选者),投票的触发点,Leader(主节点)。
  2. 进入投票状态的计时器
    Follower、Candidate 两个状态时,需要维护一个计时器,每次定时时间从150ms-300ms之间进行随机,即每个节点的每次的计时过期不一样,Follower状态时,计时器到点后,触发一轮投票。节点在收到投票请求、Leader 的心跳请求并作出响应后需要重置定时器。
  3. 投票轮次Team
    Candidate 状态的节点,每发起一轮投票,Term 加一;Term的存储。
  4. 投票机制
    每一轮一个节点只能为一个节点投赞成票,例如节点A中维护的轮次为3,并且已经为节点B投了赞成票,如果收到其他节点,投票轮次为3,则会投反对票,如果收到轮次为4的节点,是又可以投赞成票的。
  5. 成为Leader的条件
    必须得到集群中节点的大多数,即超过半数,例如如果集群中有3个节点,则必须得到两票,如果其中一台服务器宕机,剩下的两个节点,还能进行选主吗?答案是可以的,因为可以得到2票,超过初始集群中3的一半,所以通常集群中的机器各位尽量为计数,因为4台的可用性与3台的一样。

温馨提示:上述结论只是我的一些思考,我们可以带着上述思考,进入到Dleger的学习中,下一篇将从源码分析的角度来学习大神是如何实现Raft协议的Leader选主的,让我们一起期待吧。

2、日志复制

完成集群内的选主工作后,客户端向主节点发送请求,由主节点负责数据的复制,使集群内的数据保持一致性,初始状态如下图所示:

客户端向主节点发起请求,例如set 5,将数据更新为5,如下图所示:

主节点收到客户端请求后,将数据追加到Leader的日志中(但未提交),然后在下一个心跳包中将日志转发到集群内从节点,如下图所示:

从节点收到Leader的日志后,追加到从节点的日志文件中,并返回确认ACK。Leader收到从节点的确认信息后,向客户端发送确认信息。

上述的日志复制比较简单,是由于只考虑正常的情况,如果中间发生异常,该如何保证数据一致性呢?

  1. 如果 Leader 节点向从节点广播日志时,其中某个从节点发送故障宕机,该如何处理呢?
  2. 日志在什么环节进行提交呢?Leader节点在收到客户端的数据变更请求后,首先追加到主节点的日志文件中,然后广播到从节点,从节点收到日志信息,是提交日志后返回ACK,还是什么时候提交呢?
  3. 日志如何保证唯一。
  4. 如何处理网络出现分区。

我相信读者朋友肯定还有更多的疑问,本文不打算来回答上述疑问,而是带着这些问题进入到RocketMQ多副本的学习中,通过源码分析RocketMQ DLedger的实现后,再来重新总结raft协议。

亲爱的读者们,读到这里了,烦请点个赞,谢谢,下一篇将重点分析RocketMQ Dledger 多副本模块如何实现 raft 协议的选主。


作者介绍:丁威,《RocketMQ技术内幕》作者,RocketMQ 社区布道师,公众号:中间件兴趣圈 维护者,目前已陆续发表源码分析Java集合、Java 并发包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源码专栏。可以点击链接加入中间件知识星球 ,一起探讨高并发、分布式服务架构,交流源码。

原文地址:https://www.cnblogs.com/dingwpmz/p/11992094.html

时间: 2024-11-10 16:06:20

RocketMQ 多副本前置篇:初探raft协议的相关文章

基于 raft 协议的 RocketMQ DLedger 多副本日志复制设计原理

目录 1.RocketMQ DLedger 多副本日志复制流程图 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2.RocketMQ DLedger 多副本日志复制实现要点 2.1 日志编号 2.2 追加与提交机制 2.3 日志一致性如何保证 上一篇 源码分析 RocketMQ DLedger(多副本) 之日志复制(传播) ,可能有不少读者朋

Core篇——初探IdentityServer4(客户端模式,密码模式)

Core篇--初探IdentityServer4(客户端模式,密码模式) 目录 1.Oatuth2协议的客户端模式介绍2.IdentityServer4客户端模式实现3.Oatuth2协议的密码模式介绍4.IdentityServer4密码模式实现 Oatuth2协议的客户端模式介绍 Client Credentials Grant (客户端模式)是Oauth2.0协议中,四种模式自建单的一种.它由两部分构成,客户端和认证服务器.认证服务器确认客户端无误后返回一个token,客户端请求带着tok

[搜狐科技]由浅入深理解Raft协议

由浅入深理解Raft协议 2017-10-16 12:12操作系统/设计 0 - Raft协议和Paxos的因缘 读过Raft论文<In Search of an Understandable Consensus Algorithm>的同学都知道,Raft是因为Paxos而产生的.Paxos协议是出了名的难懂,而且不够详细,紧紧依据Paxos这篇论文开发出可用的系统是非常困难的.Raft的作者也说是被Paxos苦虐了无数个回合后,才设计出了Raft协议.作者的目标是设计一个足够详细并且简单易懂

[老老实实学WCF] 第四篇 初探通信--ChannelFactory

原文:[老老实实学WCF] 第四篇 初探通信--ChannelFactory 老老实实学WCF 第四篇 初探通信--ChannelFactory 通过前几篇的学习,我们简单了解了WCF的服务端-客户端模型,可以建立一个简单的WCF通信程序,并且可以把我们的服务寄宿在IIS中了.我们不禁感叹WCF模型的简单,寥寥数行代码和配置,就可以把通信建立起来.然而,仔细品味一下,这里面仍有许多疑点:服务器是如何建起服务的?我们在客户端调用一个操作后发生了什么?元数据到底是什么东西?等等.我们现在对WCF的理

【渗透课程】第二篇下-HTTP协议的请求与响应深度剖析

[渗透课程]第二篇下-HTTP协议的请求与响应深度剖析 HTTP1.1目前支持以下7种请求方法: 常见的MIME类型如下: 第一个数字有五种可能的取值: 目录 什么是请求方法?什么是请求头? HTTP请求信息由3部分组成: 1.请求方法(GET/POST) URI 协议/版本 2.请求头(Request Header) 3.请求正文 下面我们来分析一个http请求: POST http://xg.mediportal.com.cn/health/sms/verify/telephone HTTP

(转)[老老实实学WCF] 第四篇 初探通信--ChannelFactory

第四篇 初探通信--ChannelFactory 通过前几篇的学习,我们简单了解了WCF的服务端-客户端模型,可以建立一个简单的WCF通信程序,并且可以把我们的服务寄宿在IIS中了.我们不禁感叹WCF模型的简单,寥寥数行代码和配置,就可以把通信建立起来.然而,仔细品味一下,这里面仍有许多疑点:服务器是如何建起服务的?我们在客户端调用一个操作后发生了什么?元数据到底是什么东西?等等.我们现在对WCF的理解应该还处于初级阶段,我们就会觉得有许多这样的谜团了. 虽然我们生活在WCF为我们构建的美好的应

C# 串口操作系列(3) -- 协议篇,二进制协议数据解析

C# 串口操作系列(3) -- 协议篇,二进制协议数据解析 标签: c#bufferobject通讯byte硬件驱动 2010-05-27 09:54 51565人阅读 评论(215) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 我们的串口程序,除了通用的,进行串口监听收发的简单工具,大多都和下位机有关,这就需要关心我们的通讯协议如何缓存,分析,以及通知界面. 我们先说一下通讯协议.通讯协议就是通讯双方共同遵循的一套规则,定义协议的原则是尽可

C# 串口操作系列(4) -- 协议篇,文本协议数据解析

C# 串口操作系列(4) -- 协议篇,文本协议数据解析 标签: c#uiobjectstringbyte 2010-06-09 01:50 19739人阅读 评论(26) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 上一篇已经介绍了协议的组成,一个协议,一般具有 :协议头+长度+数据+校验 , 文本格式可以直观的定义回车换行是协议的结尾,所以我们可以省略数据长度,增加协议尾.即: 协议头 + 数据 + 校验 + 数据尾 . 文本方式的数据比

Raft协议实战之Redis Sentinel的选举Leader源码解析

这可能是我看过的写的最详细的关于redis 选举的文章了, 原文链接 Raft协议是用来解决分布式系统一致性问题的协议,在很长一段时间,Paxos被认为是解决分布式系统一致性的代名词.但是Paxos难于理解,更难以实现,诸如Google大牛们开发的分布式锁系统Chubby都遭遇了很多坑.Raft协议设计的初衷就是容易实现,保证对于普遍的人群都可以十分舒适容易的去理解.另外,它必须能够让人形成直观的认识,这样系统的构建者才能够在现实中进行必然的扩展. 本文从Redis Sentinel集群选择Le