共计 1583 个字符，预计需要花费 4 分钟才能阅读完成。
ISR 概念
首先 ISR 的全称为 In-Sync Replicas (同步正本集), 能够了解为与 leader 放弃同步的所有正本的汇合（蕴含 Leader 自身）。一个分区的所有正本汇合叫做 AR (Assigned Repllicas)，与 leader-replica 未能放弃同步的正本集叫做 OSR (Out-Sync Relipcas)。
ISR 动静保护了一个和 leader 正本放弃同步的正本汇合，ISR 中的正本全副都和 leader 的数据放弃同步。
为什么要设计 ISR 机制
- ISR 机制通过正本冗余机制，提供了 Kafka 音讯的高可靠性。
- ISR 机制能够做到故障转移，保障服务的可用性。
- ISR 均衡了主从架构下，复制计划的抉择（同步 / 异步 / 多数遵从少数），让使用者依据参数自行抉择。
在一些中间件中，都有正本的概念，在不同的场景下写入数据时，要求写入正本的个数也不尽相同。
例如 zk 中要求写入的节点个数大于一半才算胜利，或者有些要求高可靠性的场景，规定写入所有正本能力算胜利。
而 kafka 的 ISR 能够容许生产音讯时，依据本人的业务场景自行配置想要达到的成果：
acks=0：fire and forget，也就是我发了就算完了，后续成不胜利我都不论，这种设置下音讯的高可靠性简直没有保障，然而有极大的吞吐量。
acks=1：写入主节点就算胜利，这种设置，能够保障肯定的高可靠性，也具备不错的吞吐量。
acks=all：也就是写入 ISR 中所有的正本才算胜利，这种设置下，就能提供较高的高可靠性，然而吞吐量就绝对较低。
咱们在思考生产音讯时，ISR 机制能够敌对的让使用者依据本人的业务需要去设置参数，去抉择本人想要达到什么水平的可靠性，而不是只提供一种可靠性抉择。
【什么是生效正本？】
性能生效：节点宕机，在该节点上的正本都属于性能生效正本。
同步生效：follower 正本所在的 broker 因为带宽或者负载等因素无奈及时实现同步，导致被踢出 ISR。
ISR 伸缩控制参数
在 Kafka 0.9x 版本之前，有一个控制参数：replica.lag.max.messages 默认值为 4000，示意如果 follower 的音讯个数落后 leader 个数 4000，那么就会被踢出 ISR 列表；然而这个参数在不同场景下，很难给出一个正当的值。如果设置的很大，那么这个参数也就失去了意义，因为 ISR 列表都不会变动。如果设置的很小，那么在高吞吐的场景下，又会造成 ISR 列表的频繁变动。
因而从 Kafka 0.9x 版本开始，移除了该参数。当初用来管制的参数是：replica.log.time.max.ms。默认值是 10000ms，即 10 秒；也就是说 follower 在 10s 内都没能追上 Leader 的 LEO，就会被踢出 ISR。
阐明一下：LEO（log end offset）指日志末端位移，代表日志文件中下一条待写入音讯的 offset，这个 offset 上理论是没有音讯的。不论是 leader 正本还是 follower 正本，都有这个值。当 leader 正本收到生产者的一条音讯，LEO 通常会自增 1，而 follower 正本须要从 leader 正本 fetch 到数据后，才会减少它的 LEO。
ISR 是动静伸缩的，可能呈现 follower 全副都挂了，ISR 中只剩下 leader，那么此时设置 acks=all 就等价于 acks=1 了。这样就会对高可靠性要求的场景产生危险，那么 kafka 提供了参数：min.insync.replicas。
这个参数能够配置起码 ISR 中须要多少个正本，能力持续提供写服务。如果设置为 2，一旦 ISR 中的个数小于 2，那么就不再提供写服务，就义肯定的可用性，来保障这种高牢靠的场景需要。
总结
ISR 机制的存在是 kafka 为了均衡可靠性和可用性，不指定提供高牢靠或者高可用的服务，而是将决定权交给了使用者，让使用者通过参数来管制，到底要实现什么水平的高牢靠与高可用。
