RocketMQ中如何分析raft协议

这篇文章给大家介绍RocketMQ中如何分析raft协议，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。Raft协议是分布式领域解决一致性的又一著名协议，主要包含Leader选举、日志复制两个部分。
Follower
跟随者。Candidate
候选者。Leader
领导者(Leader)，通常我们所说的的主节点。首先3个节点初始状态为 Follower，每个节点会有一个超时时间(计时器)，其时间设置为150ms~300ms之间的随机值。当计时器到期后，节点状态从 Follower 变成 Candidate，如下图所示：
当节点状态为 Candidate，将发起一轮投票，由于是第一轮投票，设置本轮投票轮次为1，并首先为自己投上一票，正如上图所示的 NodeA 节点，Term 为1，Vote Count为1。
例如NodeA节点宕机，停止向它的从节点发送心跳，我们来看一下集群如何进行重新选主。
3个节点的选主就介绍到这里了，也许有网友会说，虽然各个节点的计时器是随机的，但也有可能同一时间，或一个节点在未收到另一个节点发起的投票请求之前变成 Candidate，即在一轮投票过程中香港云主机，有大于1个的节点状态都是 Candidate，那该如何选主呢？下面以4个节点的集群为例，来阐述上述这种情况情况下，如何进行选主。首先同时有两个节点进入Candidate状态，并开始新的一轮投票，当前投票编号为4，首先先为自己投上一票，然后向集群中的其他节点发起投票，如下图所示：
节点状态
需要引入3种节点状态：Follower(跟随者)、Candidate(候选者)，投票的触发点，Leader(主节点)。进入投票状态的计时器
Follower、Candidate 两个状态时，需要维护一个计时器，每次定时时间从150ms-300ms之间进行随机，即每个节点的每次的计时过期不一样，Follower状态时，计时器到点后，触发一轮投票。节点在收到投票请求、Leader 的心跳请求并作出响应后需要重置定时器。投票轮次Team
Candidate 状态的节点，每发起一轮投票，Term 加一；Term的存储。投票机制
每一轮一个节点只能为一个节点投赞成票，例如节点A中维护的轮次为3，并且已经为节点B投了赞成票，如果收到其他节点，投票轮次为3，则会投反对票，如果收到轮次为4的节点，是又可以投赞成票的。成为Leader的条件
必须得到集群中节点的大多数，即超过半数，例如如果集群中有3个节点，则必须得到两票，如果其中一台服务器宕机，剩下的两个节点，还能进行选主吗？答案是可以的，因为可以得到2票，超过初始集群中3的一半，所以通常集群中的机器各位尽量为奇数，因为4台的可用性与3台的一样。温馨提示：上述结论只是我的一些思考，我们可以带着上述思考，进入到Dleger的学习中，下一篇将从源码分析的角度来学习大神是如何实现Raft协议的Leader选主的，让我们一起期待吧。
完成集群内的选主工作后，客户端向主节点发送请求，由主节点负责数据的复制，使集群内的数据保持一致性，初始状态如下图所示：
如果 Leader 节点向从节点广播日志时，其中某个从节点发送故障宕机，该如何处理呢？日志在什么环节进行提交呢？Leader节点在收到客户端的数据变更请求后，首先追加到主节点的日志文件中，然后广播到从节点，从节点收到日志信息，是提交日志后返回ACK，还是什么时候提交呢？日志如何保证唯一。如何处理网络出现分区。关于RocketMQ中如何分析raft协议就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

相关推荐: docker的安装教程

这篇文章主要讲解了“docker的安装教程”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“docker的安装教程”吧！1、Docker 要求 CentOS 系统的内核版本高于 3.10 ，查看本页面的前提条件来验…