KAFKA高可用机制！

月伴飞鱼2025-08-312025-08-31

分区机制

分区策略

分区策略是决定生产者将消息发送到哪个分区的算法。

轮询策略（默认）

顺序分配，比如一个主题下有 3 个分区，那么第一条消息被发送到分区 0，第二条被发送到分区 1，第三条被发送到分区 2。

以此类推。当生产第 4 条消息时又会重新开始，即将其分配到分区 0。

随机策略

随意地将消息放置到任意一个分区上。

消息键策略

每条消息定义消息Key，同一个 Key 的所有消息都进入到相同的分区里面。

压缩机制

在 Kafka 中，压缩发生在两个地方：生产者端和 Broker 端。

生产者程序中配置 compression.type 参数即表示启用指定类型的压缩算法。

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 开启GZIP压缩
props.put("compression.type", "gzip");

Producer<String, String> producer = new KafkaProducer<>(props);

何时解压缩？

当消息到达 Consumer 端后，由 Consumer 自行解压缩还原成之前的消息。

拦截器

Kafka 拦截器分为生产者拦截器和消费者拦截器。

生产者拦截器允许在发送消息前以及消息提交成功后植入拦截器逻辑。

而消费者拦截器支持在消费消息前以及提交位移后编写特定逻辑。

当前 Kafka 拦截器的设置方法是通过参数配置完成的。

生产者和消费者两端有一个相同的参数，名字叫 interceptor.classes。

它指定的是一组类的列表，每个类就是特定逻辑的拦截器实现类。

假设第一个拦截器的完整类路径是 com.yourcompany.kafkaproject.interceptors.AddTimeStampInterceptor。

第二个类是com.yourcompany.kafkaproject.interceptors.UpdateCounterInterceptor：

Properties props = new Properties();
List<String> interceptors = new ArrayList<>();
interceptors.add("com.yourcompany.kafkaproject.interceptors.AddTimestampInterceptor");  
interceptors.add("com.yourcompany.kafkaproject.interceptors.UpdateCounterInterceptor");
props.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, interceptors);
......

副本机制

同一个分区下有多个副本，分散保存在不同的Broker 上，能够对抗部分 Broker 宕机带来的数据不可用。

副本角色

追随者副本是不对外提供服务的，任何一个追随者副本都不能响应消费者和生产者的读写请求。

所有的请求都必须由领导者副本来处理，追随者副本不处理客户端请求。

它唯一的任务就是从领导者副本异步拉取消息，并写入到自己的提交日志中，从而实现与领导者副本的同步。

当领导者副本挂掉了，或者说领导者副本所在的 Broker 宕机时。

Kafka 依托于ZooKeeper 提供的监控功能能够实时感知到，并立即开启新一轮的领导者选举。

从追随者副本中选一个作为新的领导者，老 Leader 副本重启回来后，只能作为追随者副本加入到集群中。

ISR副本集合

ISR 中的副本都是与 Leader 同步的副本，相反，不在 ISR 中的追随者副本就被认为是与 Leader 不同步的。

Leader 副本天然就在 ISR 中。

也就是说，ISR 不只是追随者副本集合，它必然包括 Leader 副本。

甚至在某些情况下，ISR 只有 Leader 这一个副本。

Follower 是否与 Leader 同步的标准:

Broker 端参数 replica.lag.time.max.ms 参数。

这个参数的含义是Follower 副本能够落后 Leader 副本的最长时间间隔，默认值是 10 秒。

只要一个 Follower 副本落后 Leader 副本的时间不连续超过 10 秒，那么 Kafka 就认为该Follower 副本与 Leader 是同步的。

即使此时 Follower 副本中保存的消息明显少于Leader 副本中的消息。

倘若该副本后面慢慢地追上了 Leader 的进度，那么它是能够重新被加回ISR 的，ISR 是一个动态调整的集合，而非静态不变的。

Unclean领导者选举

通常来说，非同步副本落后Leader 太多，因此，如果选择这些副本作为新 Leader，就可能出现数据的丢失。

在 Kafka 中，选举这种副本的过程称为 Unclean 领导者选举。

Broker 端参数 unclean.leader.election.enable 控制是否允许 Unclean 领导者选举。

选举机制

控制器（Broker）选举

控制器就是一个Borker。

在Kafka集群中，有多个Broker节点，但是它们之间需要选举出一个Leader，其他的Broker充当Follower角色。

集群中第一个启动的Broker会通过在Zookeeper中创建临时节点/controller来让自己成为控制器。

其他Broker启动时也会在Zookeeper中创建临时节点，但是发现节点已经存在，所以它们会收到一个异常。

意识到控制器已经存在，那么就会在Zookeeper中创建Watch对象，便于它们收到控制器变更的通知。

优先副本选举

如果一个分区的Leader副本不可用，就意味着整个分区不可用，此时需要从Follower副本中选举出新的Leader副本提供服务。

优先副本

指一个分区所在的AR集合的第一个副本。

比如分区1，它的AR集合是[2,0,1]，表示分区1的优先副本就是在Broker2上。

理想情况下，优先副本应该就是Leader副本。

对分区Leader副本进行选举的时候，尽可能让优先副本成为Leader副本。

控制器

控制器主要作用是在 ZooKeeper 的帮助下管理和协调整个 Kafka 集群。

集群中任意一台 Broker 都能充当控制器的角色，但是在运行过程中只能有一个 Broker 成为控制器。

Broker 在启动时，会尝试去 ZooKeeper 中创建 /controller 节点。

第一个成功创建 /controller 节点的 Broker 会被指定为控制器。

控制器的作用：

1.主题管理（创建、删除、增加分区）

2.分区重分配

3.Preferred 领导者选举

4.集群成员管理（新增 Broker、Broker 主动关闭、Broker 宕机）

自动检测新增 Broker、Broker 主动关闭及被动宕机。

比如，控制器组件会利用Watch 机制检查 ZooKeeper 的 /brokers/ids 节点下的子节点数量变更。

目前，当有新 Broker 启动后，它会在 /brokers 下创建专属的 znode 节点。

一旦创建完毕，ZooKeeper 会通过 Watch 机制将消息通知推送给控制器。

5.数据服务