posts/database/zookeeper-limitations/ about blog-comment HOT 5 OPEN

大佬分析的很详细👍

typo 可以改下，“同时DataNod也包含了一些辅助方法” -> “同时 DataNode 也包含了一些辅助方法”

from blog-comment.

大佬分析的很详细👍

typo 可以改下，“同时DataNod也包含了一些辅助方法” -> “同时 DataNode 也包含了一些辅助方法”

感谢指正，已修改

from blog-comment.

感谢大佬分享！
“数据恢复”章节有两处疑问请大佬指导：

1. 新选举出来的leader从follower提交的消息中选择最大的epoch+1作为集群新的epoch。选举产生的leader，epoch和zxid在集群内已经是最大的，那为啥还需要看follower提交的信息呢？
2. 同理，新产生的leader持有最大的lastCommittedZxid，为啥还需要从follower中获取最大的事务id呢？

from blog-comment.

@deo-prime 是不是考虑到可能存在网络延迟、部分节点可能因为故障而延迟了信息同步等情况，因此进行再次确认事务id和epoch，保持一致性。

from blog-comment.

1. 新选举出来的leader从follower提交的消息中选择最大的epoch+1作为集群新的epoch。选举产生的leader，epoch和zxid在集群内已经是最大的，那为啥还需要看follower提交的信息呢？

选举产生的 leader，epoch 已经是集群中最大。我阅读了 zookeeper 源码，也没有看到明确的解释。猜测是为了避免某些意外情况，保证新 Leader 的 epoch 是最大的。

2. 同理，新产生的leader持有最大的lastCommittedZxid，为啥还需要从follower中获取最大的事务id呢？

新 leader 获取 follower 的 zxid，是为了感知 follower 落后了哪些数据，leader 节点会维护一个滑动窗口，如果 follower 的 zxid 在位于滑动窗口之中，会采用 diff 逐条同步数据；如果 follower 的 zxid 小于滑动窗口中的最小值，那么会采用 snap 快照同步所有数据。所以在同步数据前，新 leader 需要获取 follower 的 zxid

from blog-comment.