Raft 的论文介绍了一种普适性的分布式一致性协议, 但在工程实际上, 不太可能完全照搬论文实现, 因为工程上应对很非理想状况下的场景. 工程上实现 Raft 时, 单单是集群选主这个环节, 就会引入一些 Raft 协议本来没有的概念, 比如 PreVote.
在实际使用时, 当网络分区出现时, 被隔离的节点会不断增加 currentTerm 并发起选主流程. 当网络恢复时, 它的 currentTerm 比其它所有的节点都要大, 所以, 它将导致原来的 Leader 变成 Follower 然后重新选主. 这种情况其实是非常不好的, 原来的 Leader 工作得好好的, 突然就被一个不稳定的节点给破坏了.
所以, 要引入 PreVote, 在发起选主前, 一是判断是否和其它节点能网络连通, 二是询问其它节点是否要选主. 如果 Follower 最新刚刚收到了 Leader 的心跳包, 它就不同意选主.
Leader 也要对 PreVote 请求进行响应, 而不能忽略. 因为在双节点集群时, 如果 Leader 不响应 PreVote, 那么两个节点永远都选不出新 Leader. Leader 通过心跳包和 Followers 保持联系, 如果失去联系, 它不会发起选主流程, 而是继续认为自己仍然是 Leader. 当收到 PreVote 时, 它要同意新的选主流程.
Loading ...