发布follower导致leader卡住15秒

[nickname11111234]

在发布1台follower过程中，follower启动后，leader推送log entry非常快，读请求会广播心跳到所有follower，SendEntries会频繁持有锁和handleReadIndexRequest广播心跳竞争锁，导致leader卡住。
调用链路：
NodeImpl.handleReadIndexRequest().readLock-->NodeImpl.readLeader()-->
ReplicatorGroupImpl.sendHeartbeat()-->Replicator.sendHeartbeat()-->ThreadId.lock()

每个peer一个Replicator，正在启动追数据的follower频繁持有锁，竞争等待
NodeImpl.handleReadIndexRequest().readLock会阻塞executeApplyingTasks() writeLock.lock
从而处理能力急剧下降，导致leader任务返回response超时。
1.请问这是是否需要代码优化
2.发布流程是否先发布1台learner，等数据追上，再将此机器晋升为follower，是否有发布标准可供参考
谢谢

[nickname11111234]

每个peer一个Replicator，正在启动追数据的follower在同步数据Replicator.continueSending()长时间持有锁，竞争等待
block了leader的业务

[killme2008]

可以考虑将一部分读的任务分散到其他 follower， readIndex 可以在 follower 执行的。

[nickname11111234]

readIndex都会转发到leader的

[killme2008]

选择 LeaseRead，你的问题本质上就是读抢占了写，那就想办法优化读。

[nickname11111234]

和读没有关系，这块设计有问题
在follower还没有赶上进度时，readindex不应该发送心跳来询问。
你是否了解这块逻辑？

[killme2008]

和读没有关系，这块设计有问题 在follower还没有赶上进度时，readindex不应该发送心跳来询问。 你是否了解这块逻辑？

我写的，怎么不了解

[nickname11111234]

感觉你这代码也没搞懂。

[killme2008]

你可以按自己想法来，我给你的建议就是优化读。That's all.

[nickname11111234]

和读没有一点关系，这块设计有问题。 你没明白我的问题和卡住的点。

[nickname11111234]

发布learner就没有问题，同步log entry量同样很大。
就是线性一致性读没有考虑到发布follower的情形，ThreadIdLock设计有缺陷。

[nickname11111234]