Kafka架构和高可用机制图解，阿里腾讯都在用，看不懂来找我(2)

一个副本被踢出 ISR集合的几种原因：

• 一个副本在一段时间内都没有跟得上 leader 节点，也就是跟leader节点的差距大于replica.lag.max.messages， 通常情况是 IO性能跟不上，或者CPU 负载太高，导致 broker 在磁盘上追加消息的速度低于接收leader 消息的速度。
• 一个 broker 在很长时间内(大于replica.lag.time.max.ms )都没有向 leader 发送fetch 请求， 可能是因为 broker 发生了 full GC， 或者因为别的原因挂掉了。
• 一个新 的 broker 节点，比如同一个 broker id， 磁盘坏掉，新换了一台机器，或者一个分区 reassign 到一个新的broker 节点上，都会从分区leader 上现存的最老的消息开始同步。

所以说 kafka 0.8 版本后设置了两个参数 ，replica.lag.max.messages 用来识别性能一直很慢的节点，replica.lag.time.max.ms 用来识别卡住的节点。

五、一个节点在什么情况下真正处于落后状态

从上面的情况来看，两个参数看似已经足够了，如果一个副本超过 replica.lag.time.max.ms 还没有发送fetch同步请求， 可以认为这个副本节点卡住了，然后踢出去，但是还有一种比较特殊的情况没有考虑到。

我们上文中设置replica.lag.max.messages 为4，之所以设置为 4， 是我们已经知道 producer 每次请求打过来的消息数都在 4 以下，如果我们的参数是作用于多个 topic 的情况，那么这个 producer 最大打过来的消息数目就不好估计了，或者说在经常出现流量抖动的情况下，就会出现一个什么情况呢，我们还是使用例子说明：

如果我们的 topic — foo 的 producer 因为流量抖动打过来一个 包含 4条消息的请求，我们设置的replica.lag.max.messages 还是为4， 这个时候，所有的 follower 都会因为超出落后条数被踢出 ISR集合：

然后，因为 follower 是正常的，所以下一次 fetch 请求就会又追上 leader， 这时候就会再次加入 ISR 集合，如果经常性的抖动，就会不断的移入移出ISR集合，会造成令人头疼的 告警轰炸。

这里的核心问题是，在海量的 topic 情况下，或者经常性的流量抖动情况下，我们不能对 topic 的producer 每次打过来的消息数目做任何假设，所以就不太好定出来一个 合适的eplica.lag.max.messages值

六、一个配置全部搞定

其实只有两种情况是异常的，一种就是卡住，另外一种是follower 性能慢，如果我们只根据 follower 落后 leader 多少来判断是否应该把 follower 提出ISR集合，就必须要对流量进行预测估计，怎么才能避免这种不靠谱的估计呢?

kafka 给出的方案是这样的：

对 replica.lag.time.max.ms 这个配置的含义做了增强，和之前一样，如果 follower 卡住超过这个时间不发送fetch请求， 会被踢出ISR集合，新的增强逻辑是，在 follower 落后 leader 超过eplica.lag.max.messages 条消息的时候，不会立马踢出ISR 集合，而是持续落后超过replica.lag.time.max.ms 时间，才会被踢出，这样就能避免流量抖动造成的运维问题，因为follower 在下一次fetch的时候就会跟上leader， 这样就也不用对 topic 的写入速度做任何的估计喽。

（编辑：ASP站长网）