当前位置：首页 > news >正文

福州做网站外包团队优化seo教程技术

news 2026/4/7 3:59:16

福州做网站外包团队,优化seo教程技术,网站添加锚点,wordpress插件地图文章收录在网站：http://hardyfish.top/ 文章收录在网站：http://hardyfish.top/ 文章收录在网站：http://hardyfish.top/ 文章收录在网站：http://hardyfish.top/ 分区机制分区策略分区策略是决定生产者将消息发送到哪个分区的…

文章收录在网站：http://hardyfish.top/

在这里插入图片描述

分区机制

分区策略

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

轮询策略（默认）

顺序分配。比如一个主题下有 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，就可能出现数据的丢失。