Kafka中的 ISR 机制

ISR 是什么

ISR 的全称叫做: In-Sync Replicas (同步副本集), 可以理解为和 leader 保持同步的所有副本的集合。ISR 动态维护了一个和 leader 副本保持同步副本集合,ISR 中的副本全部都和 leader 的数据保持同步。

设一个场景,有6个分区集合,分别为 [0,1,2,3,4,5],其中 leader-replica 是 0

其中 [1,2,3] 作为 follower 和 leader 的数据保持同步,而 [4,5] 未能和 leader 保持同步,那么此时,ISR=[0,1,2,3],OSR=[4,5]

如果此时副本 4 追上了 leader-replica,也就是和 leader 保持到了同步,那么此时,ISR=[0,1,2,3,4],OSR=[5]

ISR 的作用

我们知道了与 leader 保持同步的副本集后,可以做到哪些事情?

  • 当我们生产消息的时候,到底要写入多少副本才能算成功呢?
  • 当 leader 挂了之后,我们应该选择哪个 follower 来成为新的 leader 呢?

通过 ISR 就可以知晓了哪些 follower 与 leader 保持着同步,在写入消息的时候,设置写入处于 ISR 中所有的副本才算成功,在进行 leader 切换的时候,就可以从 ISR 中选择对应的 follower 成为新的 leader。

ISR 的作用是通过副本机制实现消息高可靠,服务高可用时,不可缺少的一环;这也是为什么讲到副本不得不提到 ISR 的原因。

总结

  • ISR 机制通过副本冗余机制,提供了 kafka 消息的高可靠性。
  • ISR 机制可以做到故障转移,保障服务的可用性。
  • ISR 平衡了主从架构下,复制方案的选择(同步 / 异步 / 少数服从多数),让使用者根据参数自行选择。

为什么要设计 ISR 机制

在一些中间件中,都有副本的概念,不同场景下写入数据时,要求写入副本的个数也不尽相同。例如 zk 中要求写入的节点个数大于一半才算成功,或者有些要求高可靠性的场景,规定写入所有副本才能算成功。

而 kafka 的 ISR 可以允许生产消息时,根据自己的业务场景自行配置 ACK 确认机制达到想要的效果:

  • acks=0:生产者发了就算完了,后续成不成功我都不管,这种设置下消息的高可靠性几乎没有保障,但是却有着极大的吞吐量
  • acks=1:消息写入主节点就算成功,这种设置,可以保障一定的高可靠性,也具有不错的吞吐量
  • acks=-1或all:消息必须写入 ISR 中所有的副本才算成功,这种设置下,就能提供较高的高可靠性,但是吞吐量就相对较低

ISR 虽然是动态伸缩的,可能会出现 follower 全部都挂了的情况,如果 ISR 中只剩下 leader,那么此时设置 acks=all 就等价于 acks=1 了。这样就会对高可靠性要求的场景产生危险。

kafka 提供了 min.insync.replicas 参数配置,这个参数可以配置最少 ISR 中需要多少个副本,才能继续提供写服务。如果设置为 2,一旦 ISR 中的个数小于 2,那么就不再提供写服务,牺牲一定的可用性,来保障这种高可靠的场景需求。

总结

ISR 机制的存在是 kafka 为了平衡可靠性和可用性,不指定提供高可靠或者高可用的服务,而是将决定权交给了使用者,让使用者通过参数来控制,到底要实现什么程度的高可靠与高可用。

你可能感兴趣的:(#,Kafka,kafka,ISR)