Partition 副本
发送到 Kafka Broker 上的消息,最终是以 Partition 的物理形态来存储到磁盘上的。(如图)而 Kafka 为了保证 Parititon 的可靠性,提供了 Paritition 的副本机制,然后在这些 Partition 副本集里面。存在 Leader Partition 和 Flollower Partition。生产者发送过来的消息,会先存到 Leader Partition 里面,然后再把消息复制到Follower Partition,这样设计的好处就是一旦 Leader Partition 所在的节点挂了,可以重新从剩余的Partition 副本里面选举出新的 Leader。然后消费者可以继续从新的 Leader Partition 里面获取未消费的数据。
![](https://img-blog.csdnimg.cn/0f2d453c7eb54257bb336c60f9fd2912.png)
在 Partition 多副本设计的方案里面,有两个很关键的需求:
- 副本数据的同步
- 新 Leader 的选举
ISR
这两个需求都需要涉及到网络通信,Kafka 为了避免网络通信延迟带来的性能问题,以及尽可能的保证新选举出来的 Leader Partition 里面的数据是最新的,所以设计了ISR 这样一个方案。ISR 全称是 in-sync replica,它是一个集合列表,里面保存的是和 Leader Parition 节点数据最接近的 Follower Partition如果某个 Follower Partition 里面的数据落后 Leader 太多,就会被剔除 ISR 列表。简单来说,ISR 列表里面的节点,同步的数据一定是最新的,所以后续的 Leader 选举,只需要从 ISR 列表里面筛选就行了。所以,我认为引入 ISR 这个方案的原因有两个
- 尽可能的保证数据同步的效率,因为同步效率不高的节点都会被踢出 ISR 列表。
- 避免数据的丢失,因为 ISR 里面的节点数据是和 Leader 副本最接近的。