什么是高可用
「高可用性」,指系统无间断地执行其功能的能力,代表系统的可用性程度
Kafka从0.8版本开始提供了高可用机制,可保障一个或多个Broker宕机后,其他Broker能继续提供服务
备份机制
Kafka允许同一个Partition存在多个消息副本,每个Partition的副本通常由1个Leader及0个以上的Follower组成,生产者将消息直接发往对应Partition的Leader,Follower会周期地向Leader发送同步请求
同一Partition的Replica不应存储在同一个Broker上,因为一旦该Broker宕机,对应Partition的所有Replica都无法工作,这就达不到高可用的效果
所以Kafka会尽量将所有的Partition以及各Partition的副本均匀地分配到整个集群的各个Broker上
「如下图举个例子:」
ISR机制
「ISR 副本集合」
ISR 中的副本都是与 Leader 同步的副本,相反,不在 ISR 中的追随者副本就被认为是与 Leader 不同步的
这里的保持同步不是指与Leader数据保持完全一致,只需在replica.lag.time.max.ms
时间内与Leader保持有效连接
Follower周期性地向Leader发送FetchRequest请求,发送时间间隔配置在replica.fetch.wait.max.ms
中,默认值为500
- public class FetchRequest { private final short versionId; private final int correlationId; private final String clientId; private final int replicaId; private final int maxWait; // Follower容忍的最大等待时间: 到点Leader立即返回结果,默认值500 private final int minBytes; // Follower容忍的最小返回数据大小:当Leader有足够数据时立即返回,兜底等待maxWait返回,默认值1 private final Map<TopicAndPartition, PartitionFetchInfo> requestInfo; // Follower中各Partititon对应的LEO及获取数量}
- 复制代码
各Partition的Leader负责维护ISR列表并将ISR的变更同步至ZooKeeper,被移出ISR的Follower会继续向Leader发FetchRequest请求,试图再次跟上Leader重新进入ISR
ISR中所有副本都跟上了Leader,通常只有ISR里的成员才可能被选为Leader
「Unclean领导者选举」
当Kafka中unclean.leader.election.enable
配置为true(默认值为false)且ISR中所有副本均宕机的情况下,才允许ISR外的副本被选为Leader,此时会丢失部分已应答的数据
开启 Unclean 领导者选举可能会造成数据丢失,但好处是,它使得分区 Leader 副本一直存在,不至于停止对外提供服务,因此提升了高可用性,反之,禁止 Unclean 领导者选举的好处在于维护了数据的一致性,避免了消息丢失,但牺牲了高可用性
ACK机制![](/i/l/?n=23&i=blog/878354/202306/878354-20230606221638186-2133037197.png)
标签:副本,final,实现,ISR,Partition,private,kafka,高可用性,Leader From: https://www.cnblogs.com/zqlmianshi/p/17461909.html