分区读取状态
分区读取状态一般是Leader的状态吧
9 Matching Annotations
- Apr 2025
-
book.originit.top book.originit.top
-
-
可见，副本读取状态有截断中和获取中两个：当副本执行截断操作时，副本状态被设置成 Truncating；当副本被读取时，副本状态被设置成 Fetching。
就是当前副本的状态，是否可以去Fetch,如果当前在截断中，就不能Fetch,而如果被delay了同理
-
-
book.originit.top book.originit.top
-
这是社区为了规避因多线程访问产生锁争用导致线程阻塞，从而引发请求超时问题而做的努力
解决的问题
当多线程同时执行该方法进行检查的时候，拿到锁的线程complete失败，而没拿到锁的线程直接跳过，那么如果没有其他线程再去处理的话，就永远也不会complete。
如何解决？
如果第一个线程成功将retry设置为false，那么第二个线程就会进行重试，而如果本身retry就是true，那么说明被其他线程先一步设置了，该线程不重试。但是如果多个线程顺序执行，都完成不了，那不是一样？
-
delayQueue
为什么这里有一个存储所有TimerTaskList的DelayQueue?那我为什么不直接把所有任务往队列里面塞？这样不还是O(logn)时间复杂度吗插入
Tags
Annotators
URL
-
-
book.originit.top book.originit.top
-
AR(Assigned Replicas)与ISR的区别
AR表示分区的副本，而ISR表示与Leader同步的副本
-
PartitionLeaderElectionStrategy 接口及其实现对象：定义 4 类分区 Leader 选举策略。你可以认为它们是发生 Leader 选举的 4 种场景。
什么时候会发生分区Leader选举？
Tags
Annotators
URL
-
-
book.originit.top book.originit.top
-
代码会给所有符合状态转换的副本所在的 Broker，发送 StopReplicaRequest 请求，显式地告诉这些 Broker 停掉其上的对应副本。Kafka 的副本管理器组件（ReplicaManager）负责处理这个逻辑。后面我们会用两节课的时间专门讨论 ReplicaManager 的实现，这里你只需要了解，StopReplica 请求被发送出去之后，这些 Broker 上对应的副本就停止工作了。
Kafka如何保证请求发送后能够按预期执行？
通过重试兜底保证最终一致性？同时如果主从切换的话，会进行检查然后重新进行状态同步
-
Controller给Broker发送请求是否需要保证Broker变更成功
不需要，Controller发送请求后会异步的等待broker心跳中包含的响应。同时由于MQ本身的设计能够进行容错，即旧的状态如果不对，那么会进行重试，或者刷新缓存元数据
-
尝试从元数据缓存中，
为什么要以元数据缓存为准？
-