1.概念
1.AR(Assigned Repllicas):一个分区里面所有的副本(不区分leader和follower)
2.ISR(In-Sync Replicas):能够和leader保持同步的follower+leader本身组成的集合
3.OSR(Out-Sync Replicas):不能和leader保持同步的follower集合
公式: AR=ISR+OSR
注意:1.kafka只会保证ISR集合中的所有副本保持完全同步。
2.kafka一定会保证leader接收到消息然后完全同步给ISR中的所有副本
3.ISR的机制保证了处于ISR内部的follower都可以和leader保持同步,一旦出现故障或者延迟(在一定时间内没有同步),就会被提出ISR
2.ISR踢出replica
# 默认10000 即 10秒
replica.lag.time.max.ms
# 允许 follower 副本落后 leader 副本的消息数量，超过这个数量后，follower 会被踢出 ISR
replica.lag.max.messages
一个是基于时间间隔,一个是基于消息条数
0.9版本之后移除了消息条数配置 replica.lag.max.messages
replica.lag.time.max.ms的正确理解
只要在 replica.lag.time.max.ms 时间内 follower 有同步消息，即认为该 follower 处于 ISR 中。千万不要这么认为，因为这里还涉及一个速率问题（你理解为蓄水池一个放水一个注水的问题）。
如果leader副本的消息流入速度大于follower副本的拉取速度时，你follower就是实时同步有什么用？
典型的出工不出力，消息只会越差越多，这种follower肯定是要被踢出ISR的。
当follower副本将leader副本的LEO之前的日志全部同步时，则认为该follower副本已经追赶上leader副本。
此时更新该副本的lastCaughtUpTimeMs标识。
Kafka的副本管理器（ReplicaManager）启动时会启动一个副本过期检测的定时任务，
会定时检查当前时间与副本的lastCaughtUpTimeMs差值是否大于参数replica.lag.time.max.ms指定的值。
所以replica.lag.time.max.ms的正确理解是：
follower在过去的replica.lag.time.max.ms时间内，已经追赶上leader一次了。
kafka 副本失效原因
两个方面，一个是Kafka自身的问题，另一个是外部原因
Kafka源码注释中说明了一般有两种情况会导致副本失效：
1、follower副本进程卡住，在一段时间内根本没有想leader副本发起同步请求，比如频繁的Full GC。
2、follower副本进程同步过慢，在一段时间内都无法追赶上leader副本，比如IO开销过大。
1、通过工具增加了副本因子，那么新增加的副本在赶上leader副本之前也都是处于失效状态的。
2、如果一个follower副本由于某些原因（比如宕机）而下线，之后又上线，在追赶上leader副本之前也是出于失效状态。
什么情况下OSR中的replica会重新假如ISR
当replica追上leader,就会回到ISR集合当中
3.ISR核心
动态调整
