ReadLease 的处理似乎并不严谨 about sofa-jraft HOT 13 CLOSED

仔细思考了下，这里存在的问题跟 #15 类似，issue 中描述的场景确实可能出现，出现了两个分割的 majority： (A, B）　和 (B, C)，又凑巧出现写入极少或者没有的情况， A无法及时发现 C成为了新的 leader，在 1个 hearbteat 周期内，C又刚好写入了新日志，这样 A 会认为自己是 leader，而出现了 stale read，应当在 preVote 加入租约有效期的判断，来避免 C 成为新的 leader。

感谢分析。

from sofa-jraft.

赞一个，你们的回复速度很快

from sofa-jraft.

可以参考paxos made live给出的方案， 让follewer在lease周期内不接受选举产生新的leader就可以了

from sofa-jraft.

In our implementation, all replicas implicitly grant a lease to the master of the previous Paxos instance
and refuse to process Paxos messages from any other replica while the lease is held. The master maintains
a shorter timeout for the lease than the replicas – this protects the system against clock drift. The master
periodically submits a dummy “heartbeat” value to Paxos to refresh its lease.

from sofa-jraft.

@pifuant 我的疑问是sofa-jraft目前的实现似乎没有保证这个

from sofa-jraft.

@PFZheng 我也似乎没看到相关处理

from sofa-jraft.

@PFZheng @pifuant 其实有处理的，只是不是采用时间判断的方式，而是使用定时器来避开，请参考 handleElectionTimeout 实现，这是定时器定期调用，间隔就是 election timeout。preVote 的发起只能在 lastLeaderTimestamp 过期的情况下才会发起。follower 保证在没有收到更新的 leader 请求后才会发起 preVote。

leader 和 follower 之间心跳间隔是 election timeout 的 1/10。除了定期心跳之外，所有复制请求也会更新 lastLeaderTimestamp。

from sofa-jraft.

仔细思考了下，这里存在的问题跟 #15 类似，issue 中描述的场景确实可能出现，出现了两个分割的 majority： (A, B）　和 (B, C)，又凑巧出现写入极少或者没有的情况， A无法及时发现 C成为了新的 leader，在 1个 hearbteat 周期内，C又刚好写入了新日志，这样 A 会认为自己是 leader，而出现了 stale read，应当在 preVote 加入租约有效期的判断，来避免 C 成为新的 leader。

感谢分析。

看了这个，的确可以用同一方法来解决😊。另外，我建议可以另外提供一个lease timeout的参数。

from sofa-jraft.

            this.checkReplicator(peer);
            if (nowMs - replicatorGroup.getLastRpcSendTimestamp(peer) <= options.getElectionTimeoutMs()) {
                aliveCount++;
                continue;
            }
            deadNodes.addPeer(peer);
 

这里的replicatorGroup.getLastRpcSendTimestamp(peer)是不是应该判断下是已经收到peer response确认过的，而不单单只是SendTimestamp。

from sofa-jraft.

@pifuant 他是 Replicator 里的 lastRpcSendTimestamp，每次在 rpc response 返回后更新的。名字可能误导你了。

from sofa-jraft.

@killme2008 thx, 由于时钟偏移， 判断lease有效时， 是不是用小于options.getElectionTimeoutMs()的某个值代替options.getElectionTimeoutMs()更好一点呢

from sofa-jraft.

@pifuant 因为 heartbeat 的周期是 electionTimeout 的十分之一，这个小于getElectionTimeoutMs多少的值如何设置都不会完全合理，保持目前这个判断可以接受了。

from sofa-jraft.

这个 bug 已在 v1.2.4中发布解决，先关闭了

from sofa-jraft.