ReplicaManager主要负责日志的写入以及副本的同步，如果ack配置的不是0，则需要等待副本写入满足acks才会回复响应。同时ReplicaManager会定时检查ISR是否已经不再同步，主要是看当前副本的LEO与Leader的LEO是否相同，或者上次lag的时间是否超过replica.lag.time.max.ms，默认30s
8 Matching Annotations
- Apr 2025
-
book.originit.top book.originit.top
-
-
book.originit.top book.originit.top
-
def isReplicaInSync: Boolean = lag.isDefined && lag.get <= 0
副本处于ISR中居然是lag为0
-
副本对外提供读取服务
-
- Mar 2025
-
book.originit.top book.originit.top
-
Follower 副本拉取消息后写入副本；
不需要顾及acks，直接写入副本即可
-
-
book.originit.top book.originit.top
-
但是为什么 AbstractFetcherThread 线程总要不断尝试去做截断呢？这是因为，分区的 Leader 可能会随时发生变化。每当有新 Leader 产生时，Follower 副本就必须主动执行截断操作，将自己的本地日志裁剪成与 Leader 一模一样的消息序列，甚至，Leader 副本本身也需要执行截断操作，将 LEO 调整到分区高水位处。
当leader变更时，follower需要truncate自己的日志来保证与leader一致，而leader切换的时候，自身也需要truncate到HW来保持数据的一致性，但是这样会丢消息，当然如果没有到HW，那么需要所有节点同步的消息应该收不到回复
-
-
book.originit.top book.originit.top
-
Leader如何知道当前的同步进度？
partition的高水位线表示当前已同步的offset，这些消息是安全的，可以被consumer消费，因此通过这个可以看到消息的同步进度 参考
-
如果Leader挂了，follower要达到什么标准才能成为leader？是否可能丢失数据？
-
副本同步的时候，谁主动进行同步？
-