作者回复: 通过HW机制。leader处的HW要等所有follower LEO都越过了才会前移
作者回复: 1. 通过比较follower和leader的最新消息位移或末端消息位移(Log End Offset, LEO)
2. 嗯,就一直少一个副本了
作者回复: 试试到ZooKeeper中手动删除/controller节点。这通常都是因为Controller与ZooKeeper状态不同步导致的。
试试这个命令吧: rmr /controller
确保在业务低峰时刻执行这个命令
作者回复: 一个分区有3个副本,一个leader,2个follower。producer向leader写了10条消息,follower1从leader处拷贝了5条消息,follower2从leader处拷贝了3条消息,那么leader副本的LEO就是10,HW=3;follower1副本的LEO是5。这样说清楚些吗
作者回复: 初衷是好的。难点在于我们如何区分什么数据是新的什么是老的:)
作者回复: Producer端认为消息已经成功提交的条件是:ISR中所有副本都已经保存了该消息,但producer并没有指定ISR中需要几个副本。这就是min.insync.replicas参数的作用。
正常情况下,如果5个副本都在ISR中,那么它们必须都同步才行,但如果4个副本不在ISR中了,不满足min.insync.replicas了,此时broker会抛出异常给producer,告诉producer这条消息无法正确保存
作者回复: 你是如何确定消息发送成功了呢?可以使用KafkaConsumer.endOffsets验证下消息确实写入成功了,
作者回复: 有兴趣看看KIP-392的设计吧(https://cwiki.apache.org/confluence/display/KAFKA/KIP-392%3A+Allow+consumers+to+fetch+from+closest+replica)
作者回复: 只能把r2启动起来了,而且有可能出现数据丢失。因为Kafka承诺不丢消息也是有条件的
作者回复: 也不算丢数据,默认配置下如果ISR为空了,这个分区就不可用了,producer也无法向这个分区发送任何消息了。对于这种情况,Kafka不认为是丢数据
作者回复: 不会阻塞,你可以认为是不断轮询状态
作者回复: 1. 比较follower LEO赶上leader LEO时的时间差是否超过了10s
2. 不停地fetch,然后处理,之后再fetch。具体间隔没法配置
作者回复: ISR中的follower副本非常有可能与leader不一致的。如果leader挂了,其他follower又都没有保存该消息,那么该消息是可能丢失的。如果你要避免这种情况,设置producer端的acks=all吧
作者回复: 1. 计算follower的LEO落后leader LEO的时间
2. follower被踢出ISR不代表它有问题了,至少不表示它挂了,可能只是阶段性的落后leader。当追上后还是可以将其重新加入到ISR中的
作者回复: 不会啊。
作者回复: acks=all保证ISR中的所有副本都要同步