标签:image ica tail 因此 日志 附加 持久化 内容 输入
Raft协议
Raft协议基于日志实现了一致性
实现备份的是机制:复制状态机Replicated State Machine,如果两个相同的、确定性的状态机从同一状态开始,以相同顺序输入相同的日志,则两个状态机最终也会保持一致
Raft了实现Consensus Module
Consensus Module作为一致性模块对外服务,负责接收客户端的消息,响应请求,并追加到本地日志,一致性模块保证每个机器上的log的一致性
请求到来时,带上(term,commitindex)和append log 去要求Follower追加消息,Follower会先判断(term,index)是否和当前最大的消息相同,如果相同就会追加,否则会拒绝
一致性模块负责复制消息到其他服务器节点,本地日志commit成功后立即应用到状态机
CNew用于服务器增加或者减少节点的情况
Leader:处理与客户端交互,处理消息
Follower:选民,转发请求到leader
Candidate:候选人,可以参选成为leader,不是所有Follower都能成为Candidate,只有数据较完整的才可以。如果Candidate发现自己的term落后了就会退回到Follower
RequestVote:选举期间的RPC消息
AppendEntries:leader选出后向Follow复制日志的RPC消息,心跳也是AppendEntries,不过日志内容为空
leader向follower复制日志时,会带上当前最新的(该日志前)term和index,follower接收到请求后,会先比对自身最新的日志的term和index,匹配时才会追加,否则拒绝,这时leader会往前找term 和index,尝试和follower匹配成功,然后从该位置开始复制日志到follower
不能提交之前任务内的日志作为Commit 点
如果一个Follower在一定时间没有收到Leader的心跳,则开始重新选主
Follower把自己的状态变更为Candidate,并递增本地term,并持久化,向其他机器拉票,并给自己投票,开始等待,直到
leader发现log已经被多数派的主机写盘了,就认为commited
将Cnew发送出去,如果Follower发现自己已经不在拓扑结构中,则退出
leader在选举刚结束后,可能有一些Entry是已经提交的,有一些是还未提交的,因此需要提交一个No op Entry来确保和Follower达到一致了,同时,也为了防止客户端来了新请求后不能及时到达
到底是如果commit的,Raft是如果保证状态机一致性的
情况1:
client - > leader -> Log AppendEntries - > 多数派确认 ->已经commited -> 返回client:成功
由于已经到多数机器上,即使重新选主,也一定会带有最新的log
但是这种情况呢
情况2:
client - > leader -> Log AppendEntries - > 未获取多数派确认 ->不算作Commited -> 返回client:失败重试
返回给client失败了,此时若leader断开网络,可能出现部分确认的实例被选中为leader?岂不是实际成功了
Raft维护的以下属性是否可以解释此问题:
依据上述特性,出现情况2时,不满足特性3,client会收到执行失败的响应,此时应该做的是不断重试,直到成功,也就是说raft协议允许情况3,也要求client如果想要强一致性,就得不断的重试
raft保证了已提交日志的一致性
follower发现自己的term和logindex 比leader还大怎么办?
截断或leader退化成follower?
leader何时告诉follower log已提交了?
Raft约束日志是连续commit的,leader维护最大已经commit的日志id,并将这个信息附加到AppendEntries告知follower,follower了解到之后即可将本机已有的且已经commit的日志应用到本地的状态机。
参考文章
https://blog.csdn.net/weixin_39843367/article/details/82498536
https://blog.csdn.net/baijiwei/article/details/78760308
标签:image ica tail 因此 日志 附加 持久化 内容 输入
原文地址:https://www.cnblogs.com/windliu/p/11080544.html