消息队列Kafka从入门到高级应用

最新推荐文章于 2024-04-26 17:01:28 发布
最新推荐文章于 2024-04-26 17:01:28 发布
阅读量834 收藏 1
点赞数 1
分类专栏： 消息队列 文章标签： kafka java 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/hrd535523596/article/details/126160622
版权

本文章以小破某站的某硅谷资料为入门基础，再配合个人理解整理的资料，若涉及等问题，请及时联系我并删除整改。

借鉴资料：Spring-Boot整合kafka - CSDN资料

文章目录

架构

在这里插入图片描述

1）Producer **：**消息生产者，就是向 kafka broker 发消息的客户端；

2）Consumer **：**消息消费者，向 kafka broker 取消息的客户端；

3）Consumer Group （CG）：**消费者组，由多个 consumer 组成。**消费者组内每个消费者负

**责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。**所

有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4）Broker **：**一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker

可以容纳多个 topic。

5）Topic **：**可以理解为一个队列，生产者和消费者面向的都是一个 topic；

6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，

一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

7）Replica：副本，为保证集群中的某个节点发生故 障时，该节点上的 partition 数据不丢失，

且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，

一个 leader 和若干个 follower。

8）leader：**每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对

象都是 leader。

9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据

的同步。leader 发生故障时，某个 follower 会成为新的 follower。

工作流程

topic 是逻辑上的概念，而 partition 是物理上的概念

每个 partition 对应于一个 log 文件，该 log 文件中存储的就是 producer 生产的数据

Producer 生产的数据会被不断追加到该log 文件末端，且每条数据都有自己的 offset。

消费者组中的每个消费者，都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费

“.index”文件存储大量的索引信息，

“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中 message 的物理偏移地址

命令行操作

查看操作主题topic命令参数

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh  其他操作 --topic 主题名 其他操作
参数描述
–bootstrap-server <String: server toconnect to>连接的 Kafka Broker 主机名称和端口号
–topic <String: topic>操作的 topic 名称
–create创建主题
–delete删除主题
–alter修改主题
–list查看所有主题
–describe查看主题详细描述
–partitions <Integer: # of partitions>设置分区数
–replication-factor<Integer: replication factor>设置分区副本
–config <String: name=value>更新系统默认的配置

修改分区数（注意：分区数只能增加，不能减少）

生产者命令参数

参数描述
–bootstrap-server <String: server toconnect to>连接的 Kafka Broker 主机名称和端口号
–topic <String: topic>操作的 topic 名称

发送消息

[atguigu@hadoop102 kafka]$ bin/kafka-console-producer.sh --bootstrap-server hadoop102:9092 --topic first
>hello world
>atguigu atguigu

消费者命令参数

参数描述
–bootstrap-server <String: server toconnect to>连接的 Kafka Broker 主机名称和端口号
–topic <String: topic>操作的 topic 名称
–from-beginning从头开始消费
–group <String: consumer group id>指定消费者组名称

消费信息

（1）消费 first 主题中的数据
[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first
（2）把主题中所有的数据都读取出来（包括历史数据）
[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --from-beginning --topic first

生产者

发生原理

两个线程—— main 线程和 Sender 线程

在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程将消息发送给 RecordAccumulator，

Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka Broker

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nziqSh03-1659598509381)(kafka笔记.assets/image-20220521150623653.png)]

只需在异步发送的基础上，再调用一下 get()方法即可。

package com.atguigu.kafka.producer;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;
import java.util.concurrent.ExecutionException;
public class CustomProducerSync {

	public static void main(String[] args) throws
		InterruptedException, ExecutionException {
      // 1. 创建 kafka 生产者的配置对象
      Properties properties = new Properties();
      // 2. 给 kafka 配置对象添加配置信息

      properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092");
      // key,value 序列化（必须）：key.serializer，value.serializer
      properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

      properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
      // RecordAccumulator：缓冲区大小，默认 32M：buffer.memory
 			properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG,33554432);
      // compression.type：压缩，默认 none，可配置值 gzip、snappy、lz4 和 zstd
			properties.put(ProducerConfig.COMPRESSION_TYPE_CONFIG,"snappy");               
                    
      StringSerializer.class.getName());
      // 3. 创建 kafka 生产者对象
      KafkaProducer<String, String> kafkaProducer = new 
      KafkaProducer<String, String>(properties);
      // 4. 调用 send 方法,发送消息
      for (int i = 0; i < 10; i++) {
        // 异步发送 默认
        kafkaProducer.send(new ProducerRecord<>("first","kafka" + i), 
          // 1.添加回调
          new Callback() {
            @Override
            public void onCompletion(RecordMetadata metadata, Exception exception) {
              if (exception == null) {
                // 没有异常,输出信息到控制台
                System.out.println(" 主题： " + metadata.topic() + "->" + "分区：" + metadata.partition());
              } else {
                // 出现异常打印
                exception.printStackTrace();
              }
            }
          }
        );
        // 2.同步发送
        kafkaProducer.send(new ProducerRecord<>("first","kafka" + i)).get();
      }
 		// 5. 关闭资源
 		kafkaProducer.close();
  } 
  
}

kafkaTemplate提供了一个回调方法addCallback，我们可以在回调方法中监控消息是否发送成功 或 失败时做补偿处理，有两种写法

生产者发送代码示例

@RestController
public class KafkaProducer {
    @Autowired
    private KafkaTemplate<String, Object> kafkaTemplate;
    
    // 发送消息
    @GetMapping("/kafka/callbackOne/{message}")
		public void sendMessage2(@PathVariable("message") String callbackMessage) {
      kafkaTemplate.send("topic1", callbackMessage).addCallback(success -> {
          // 消息发送到的topic
          String topic = success.getRecordMetadata().topic();
          // 消息发送到的分区
          int partition = success.getRecordMetadata().partition();
          // 消息在分区内的offset
          long offset = success.getRecordMetadata().offset();
          System.out.println("发送消息成功:" + topic + "-" + partition + "-" + offset);
      }, failure -> {
          System.out.println("发送消息失败:" + failure.getMessage());
      });
	}
  
  @GetMapping("/kafka/callbackTwo/{message}")
  public void sendMessage3(@PathVariable("message") String callbackMessage) {
    kafkaTemplate.send("topic1", callbackMessage).addCallback(
      new ListenableFutureCallback<SendResult<String, Object>>() {
        @Override
        public void onFailure(Throwable ex) {
          System.out.println("发送消息失败："+ex.getMessage());
        }

        @Override
        public void onSuccess(SendResult<String, Object> result) {
          System.out.println("发送消息成功：" + result.getRecordMetadata().topic() + "-"
                             + result.getRecordMetadata().partition() + "-" + 
                             result.getRecordMetadata().offset());
        }
    });
  }

}

分区策略

方便在集群中扩展，提高并发

需要将 producer 发送的数据封装成一个 ProducerRecord 对象

public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value, Iterable<Header> headers) {	... ... }

在这里插入图片描述

  1. 指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

  2. 没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

  3. 既没有 partition 值又没有 key 值的情况下，**采用Sticky Partition（黏性分区器）**第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。

    并尽可能一直使用该分区，待该分区的 batch 已满或者已完成，Kafka再随机一个分区进行使用（和上一次的分区不同）

  • 自定义分区器

定义类实现 Partitioner 接口，重写 partition()方法

package com.atguigu.kafka.producer;

import org.apache.kafka.clients.producer.Partitioner;
import org.apache.kafka.common.Cluster;

/**
* 1. 实现接口 Partitioner
* 2. 实现 3 个方法:partition(返回信息对应的分区),close(关闭资源),configure(配置方法)
* 3. 编写 partition 方法,返回分区号
*/
public class MyPartitioner implements Partitioner {

}

使用分区器的方法，在生产者的配置中添加分区器参数

Properties properties = new Properties();
....
// 添加自定义分区器
properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,"com.atguigu.kafka.producer.MyPartitioner");

或者，在application.propertise中配置自定义分区器，配置的值就是分区器类的全路径名

# 自定义分区器
spring.kafka.producer.properties.partitioner.class=com.atguigu.kafka.producer.MyPartitioner

可靠性

**ack 应答机制 **

topic 的每个 partition 收到

producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果

producer 收到 ack，就会进行下一轮的发送，否则重新发送数据

在这里插入图片描述

方案优点缺点
半数以上完成同步，就发送ack延迟低选举新的 leader 时，容忍 n 台节点的故障，需要 2n+1 个副本
全部完成同步，才发送ack选举新的 leader 时，容忍 n 台节点的故障，需要 n+1 个副本延迟高

replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。

Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集合。

当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。

如果 follower长时间 未 向 leader 同 步 数 据 ， 则 该 follower 将 被 踢 出 ISR 。

生产者参数

参数名称描述
bootstrap.servers生产者连接集群所需的 broker 地 址清单，多个中间用逗号隔开
key.serializer 和 value.serializer指定发送消息的 key 和 value 的序列化类型。一定要写全类名
buffer.memoryRecordAccumulator 缓冲区总大小，默认 32m
batch.size缓冲区一批数据最大值，默认 16k适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加
linger.ms如果数据迟迟未达到 batch.size，sender 等待 linger.time之后就会发送数据。单位 ms，默认值是 0ms，表示没有延迟。生产环境建议该值大小为 5-100ms 之间。
max.in.flight.requests.per.connection允许最多没有返回 ack 的次数，默认为 5，开启幂等性要保证该值是 1-5 的数字
retries当消息发送出现错误的时候，系统会重发消息。retries表示重试次数。默认是 int 最大值，2147483647。还想保证消息的有序性，需要设置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1
retry.backoff.ms两次重试之间的时间间隔，默认是 100ms
enable.idempotence是否开启幂等性，默认 true，开启幂等性
compression.type生产者发送的所有数据的压缩方式。默认是 none，也就是不压缩。支持压缩类型：none、gzip、snappy、lz4 和 zstd

对数据的可靠性要求不是很高，没必要等 ISR 中的 follower 全部接收成功，Kafka 为用户提供了三种可靠性级别

acks参数可能影响
0producer 不等待 broker 的 ack当 broker 故障时有可能丢失数据
1producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack在 follower同步成功之前 leader 故障，那么将会丢失数据
-1(all)producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才返回 ack在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复
// 设置 acks
 properties.put(ProducerConfig.ACKS_CONFIG, "all");
 // 重试次数 retries，默认是 int 最大值，2147483647
 properties.put(ProducerConfig.RETRIES_CONFIG, 3);

幂等性

数据传递语义

至少一次（At Least Once）= ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2

​ 保证数据不丢失，但是不能保证数据不重复

最多一次（At Most Once）= ACK级别设置为0，保证数据不重复，但是不能保证数据不丢失

精确一次（Exactly Once）：对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不丢失

Kafka 0.11版本以后，引入了一项重大特性：幂等性和事务

精确一次（Exactly Once） = 幂等性 + 至少一次（ ack=-1 + 分区副本数 >=2 + ISR 最小副本数量 >=2 ）

重复数据的判断标准：具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。

其 中PID是Kafka每次重启都会分配一个新的；Partition 表示分区号；Sequence Number是单调自增的

在这里插入图片描述

  • 使用

开启参数 enable.idempotence 默认为 true，false 关闭

生产者事务

开启事务，必须开启幂等性

Producer 在使用事务功能前，必须先自定义一个唯一的 transactional.id。

有 了 transactional.id，即使客户端挂掉了，它重启后也能继续处理未完成的事务

// 1. 创建 kafka 生产者的配置对象
Properties properties = new Properties();
// 2. 给 kafka 配置对象添加配置信息
// 给 kafka 配置对象添加配置信息：bootstrap.servers
 properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
// key,value 序列化（必须）：key.serializer，value.serializer
	properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
  	"org.apache.kafka.common.serialization.StringSerializer");
 	properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
		"org.apache.kafka.common.serialization.StringSerializer");
 	.....
 
// 设置事务 id（必须），事务 id 任意起名
	properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "transaction_id_0");

// 3. 创建 kafka 生产者对象
KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);
// 初始化事务
kafkaProducer.initTransactions();
// 开启事务
kafkaProducer.beginTransaction();
try {
  // 4. 调用 send 方法,发送消息
  for (int i = 0; i < 5; i++) {
    // 发送消息
    kafkaProducer.send(new ProducerRecord<>("first", "atguigu " + i));
  }
  // int i = 1 / 0;
  // 提交事务
  kafkaProducer.commitTransaction();
} catch (Exception e) {
  // 终止事务
  kafkaProducer.abortTransaction();
} finally {
  // 5. 关闭资源
  kafkaProducer.close();
}
  • 整合spring boot

生产者事务示例代码，使用 KafkaTemplate 的 executeInTransaction 方法来声明事务

@GetMapping("/kafka/transaction")
public void sendMessage7(){
    // 声明事务：后面报错消息不会发出去
    kafkaTemplate.executeInTransaction(operations -> {
        operations.send("topic1","test executeInTransaction");
        throw new RuntimeException("fail");
    });
    // 不声明事务：后面报错但前面消息已经发送成功了
   kafkaTemplate.send("topic1","test executeInTransaction");
   throw new RuntimeException("fail");
}

Kafka 的事务一共有如下 5 个 API

// 1 初始化事务
void initTransactions();
// 2 开启事务
void beginTransaction() throws ProducerFencedException;
// 3 在事务内提交已经消费的偏移量（主要用于消费者）
void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets,
 String consumerGroupId) throws 
ProducerFencedException;
// 4 提交事务
void commitTransaction() throws ProducerFencedException;
// 5 放弃事务（类似于回滚事务的操作）
void abortTransaction() throws ProducerFencedException;

数据有序

单分区内，有序

多分区，分区与分区间无序

负载平衡

正常下，Kafka会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量均匀

  • 特殊情况

但是如果某 些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，

其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡

参数名称描述
auto.leader.rebalance.enable默认是 true。 自动 Leader Partition 平衡。生产环境中，leader 重选举的代价比较大，可能会带来性能影响，建议设置为 false 关闭
leader.imbalance.per.broker.percentage默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡
leader.imbalance.check.interval.seconds默认值 300 秒。检查 leader 负载是否平衡的间隔时间

Kafka Broker

一个kafka运行实例叫做一个broker

Zookeeper中存储的Kafka 信息

1）/kafka/brokers/ids ： [0,1,2] 记录有哪些服务器

2）/kafka/brokers/topics/first/partitions/0/state ：{“leader”:1 ,“isr”:[1,0,2] } 记录谁是Leader，有哪些服务器可用

3）/kafka/controller ：{“brokerid”:0}辅助选举Leader

（1）启动 Zookeeper 客户端。

[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkCli.sh

（2）通过 ls 命令可以查看 kafka 相关信息。

[zk: localhost:2181(CONNECTED) 2] ls /kafka

在这里插入图片描述

broker总体工作流程

Broker参数

参数名称描述
replica.lag.time.max.msISR 中，如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值，默认 30s
auto.leader.rebalance.enable默认是 true。 自动 Leader Partition 平衡
leader.imbalance.per.broker.percentage默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡
leader.imbalance.check.interval.seconds默认值 300 秒。检查 leader 负载是否平衡的间隔时间
log.segment.bytesKafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分 成块的大小，默认值 1G
log.index.interval.bytes默认 4kb，kafka 里面每当写入了 4kb 大小的日志（.log），然后就往 index 文件里面记录一个索引
log.retention.hoursKafka 中数据保存的时间，默认 7 天
log.retention.minutesKafka 中数据保存的时间，分钟级别，默认关闭
log.retention.msKafka 中数据保存的时间，毫秒级别，默认关闭
log.retention.check.interval.ms检查数据是否保存超时的间隔，默认是 5 分钟
log.retention.bytes默认等于-1，表示无穷大。超过设置的所有日志总大小，删除最早的 segment
log.cleanup.policy默认是 delete，表示所有数据启用删除策略；如果设置值为 compact，表示所有数据启用压缩策略
num.io.threads默认是 8。负责写磁盘的线程数。整个参数值要占总核数的 50%
num.replica.fetchers副本拉取线程数，这个参数占总核数的 50%的 1/3
num.network.threads默认是 3。数据传输线程数，这个参数占总核数的50%的 2/3
log.flush.interval.messages强制页缓存刷写到磁盘的条数，默认是 long 的最大值，9223372036854775807。一般不建议修改交给系统自己管理
log.flush.interval.ms每隔多久，刷数据到磁盘，默认是 null。一般不建议修改，交给系统自己管理

副本

  1. Kafka 副本作用：提高数据可靠性

  2. Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率

  3. Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据

  4. Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）。AR = ISR + OSR

    ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢 出 ISR。该时间阈值由 replica.lag.time.max.ms参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader

    OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本

Leader选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为**Controller Leader**，负责管理集群broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。

Controller 的信息同步工作是依赖于 **Zookeeper **的。

在这里插入图片描述

故障处理细节

Log文件中的HW和LEO

LEO：每个副本的最后一个offset

HW：指的是消费者能见到的最大的offset，ISR 队列中最小的 LEO

1）Follower 故障

  1. Follower发生故障后会被临时踢出ISR
  2. 这个期间Leader和Follower继续接收数据
  3. 待该Follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取，从HW开始向Leader进行同步
  4. 等该Follower的LEO大于等于该Partition的HW，即Follower追上Leader之后，就可以重新加入ISR了

2）Leader 故障

  1. Leader发生故障之后，会从ISR中选出一个新的Leader
  2. 为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复

文件存储

高效读写数据

1）Kafka本身是分布式集群，可以采用分区技术，并行度高

2）读数据采用稀疏索引，可以快速定位要消费的数据

3）顺序写磁盘

4）页缓存 + 零拷贝技术

分区

Topic是逻辑上的概念，而 partition 是物理上的概念，每个partition对应于一个 log 文件，该log文件中存储的就是Producer生产的数据。

Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制

将每个partition分为多个segment。每个segment包括：“.index文件，.log文件和.timeindex等文件“。

这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号，例如：first-0。

.log 日志文件

.index 偏移量索引文件

.timeindex 时间戳索引文件

在这里插入图片描述

Log文件和Index文件详解

根据目标offset定位Segment文件

找到小于等于目标offset的最大offset对应的索引项

定位到log文件

向下遍历找到目标Record

  1. index为稀疏索引，大约每往log文件写入4kb数据，会往index文件写入一条索引。参log.index.interval.bytes默认4kb

  2. Index文件中保存的offset为相对offset，这样能确保offset的值所占空间不会过大，因此能将offset的值控制在固定大小

日志存储参数配置

参数描述
log.segment.bytesKafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分成块的大小，默认值 1G
log.index.interval.bytes默认 4kb，kafka 里面每当写入了 4kb 大小的日志（.log），然后就往 index 文件里面记录一个索引，稀疏索引

文件清理策略

Kafka 中默认的日志保存时间为 7 天，可以通过调整如下参数修改保存时间

参数描述
log.retention.hours最低优先级小时，默认 7 天
log.retention.minutes分钟
log.retention.ms最高优先级毫秒
log.retention.check.interval.ms负责设置检查周期，默认 5 分钟

日志清理策略有 delete 和 compact 两种

  • delete 日志删除

将过期数据删除，log.cleanup.policy = delete 所有数据启用删除策略

（1）基于时间：默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。

（2）基于大小：默认关闭。超过设置的所有日志总大小，删除最早的 segment。

​ log.retention.bytes，默认等于-1，表示无穷大。

  • compact 日志压缩

对于相同key的不同value值，只保留最后一个版本，压缩后的offset可能是不连续的

log.cleanup.policy = compact 所有数据启用压缩策略

顺序写磁盘

Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。

省去了大量磁头寻址的时间

页缓存 + 零拷贝

零拷贝：Kafka Broker应用层不关心存储的数据，所以就不用走应用层，传输效率高

PageCache页缓存

Kafka重度依赖底层操作系统提供的PageCache功 能。

当上层有写操作时，操作系统只是将数据写PageCache。

当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。

实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。

参数描述
log.flush.interval.messages强制页缓存刷写到磁盘的条数，默认是 long 的最大值9223372036854775807。一般不建议修改，交给系统
log.flush.interval.ms每隔多久，刷数据到磁盘，默认是 null。一般不建议修改，交给系统

消费者

消费方式

consumer 采用 pull（拉）模式从 broker 中读取数据。

pull模式不足之处是，如果Kafka没有数据，消费者可能会陷入循环中，一直返回空数据。

消费者组

Consumer Group（CG）：消费者组，由多个consumer组成。

  1. 形成一个消费者组的条件，是所有消费者的 groupid 相同
  2. 消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费
  3. 消费者组之间互不影响**，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者**
  4. 如果向消费组中添加更多的消费者，超过主题分区数量**，则有一部分消费者就会闲置，不会接收任何消息

消费者参数

参数名称描述
bootstrap.servers向 Kafka 集群建立初始连接用到的 host/port 列表
key.deserializer 和 value.deserializer指定接收消息的 key 和 value 的反序列化类型（一定要写全类名
group.id标记消费者所属的消费者组
enable.auto.commit默认值为 true，消费者会自动周期性地向服务器提交偏移量
auto.commit.interval.ms如果设置了 enable.auto.commit 的值为 true， 则该值定义了消费者偏移量向 Kafka 提交的频率，默认 5s
auto.offset.resetearliest：自动重置偏移量到最早的偏移量。 latest：默认，自动重置偏移量为最新的偏移量。 none：如果消费组原来的（previous）偏移量不存在，则向消费者抛异常。 anything：向消费者抛异常
offsets.topic.num.partitions__consumer_offsets 的分区数，默认是 50 个分区。
heartbeat.interval.msKafka 消费者和 coordinator 之间的心跳时间，默认 3s。
session.timeout.msKafka 消费者和 coordinator 之间连接超时时间，默认 45s。超过该值，该消费者被移除，消费者组执行再平衡
max.poll.interval.ms消费者处理消息的最大时长，默认是 5 分钟。超过该值，该消费者被移除，消费者组执行再平衡
fetch.min.bytes默认 1 个字节。消费者获取服务器端一批消息最小的字节数
fetch.max.wait.ms默认 500ms。如果没有从服务器端获取到一批数据的最小字节数。该时间到，仍然会返回数据
max.poll.records一次 poll 拉取数据返回消息的最大条数，默认是 500 条

注意：

在消费者 API 代码中必须配置消费者组 id。

命令行启动消费者不填写消费者组id 会被自动填写随机的消费者组 id。

package com.atguigu.kafka.consumer;
import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import org.apache.kafka.common.TopicPartition;
import java.time.Duration;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Properties;
public class CustomConsumerPartition {
  public static void main(String[] args) {
    // 创建消费者的配置对象
    Properties properties = new Properties();
 		// 给消费者配置对象添加参数
  	properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092");
  	// 配置序列化 必须
  	properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, 
    	StringDeserializer.class.getName());
    properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,
    	StringDeserializer.class.getName());
     // 配置消费者组（必须），名字可以任意起
    properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");
    
    // 创建消费者对象
    KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
    /*
    	// 注册要消费的主题（可以消费多个主题）
    	ArrayList<String> topics = new ArrayList<>();
      topics.add("first");
      kafkaConsumer.subscribe(topics);
    */

    // 消费某个主题的某个分区数据
    ArrayList<TopicPartition> topicPartitions = new ArrayList<>();
    topicPartitions.add(new TopicPartition("first", 0));
    kafkaConsumer.assign(topicPartitions);

    // 拉取数据打印
    while (true){
      ConsumerRecords<String, String> consumerRecords = 
        kafkaConsumer.poll(Duration.ofSeconds(1));
     for (ConsumerRecord<String, String> consumerRecord : 
     		consumerRecords) {
       	System.out.println(consumerRecord);
     }
   }
 } 
}
  • 整合spring boot

批量消费

设置application.prpertise开启批量消费即可

# 设置批量消费
spring.kafka.listener.type=batch
# 批量消费每次最多消费多少条消息
spring.kafka.consumer.max-poll-records=50

接收消息时用 **List **来接收，监听代码如下

@KafkaListener(id = "consumer2",groupId = "felix-group", topics = "topic1")
public void onMessage3(List<ConsumerRecord<?, ?>> records) {
    System.out.println(">>>批量消费一次，records.size()="+records.size());
    for (ConsumerRecord<?, ?> record : records) {
        System.out.println(record.value());
    }
}

自定义异常处理器

通过ConsumerAwareListenerErrorHandler 异常处理器，可处理consumer在消费时发生的异常

新建一个 类型异常处理方法，用@Bean注入放到@KafkaListener注解的errorHandler属性里面，当监听抛出异常的时候，则会自动调用异常处理器

// 新建一个异常处理器，用@Bean注入
@Bean
public ConsumerAwareListenerErrorHandler consumerAwareErrorHandler() {
    return (message, exception, consumer) -> {
        System.out.println("消费异常："+message.getPayload());
        return null;
    };
}

// 将这个异常处理器的BeanName放到@KafkaListener注解的errorHandler属性里面
@KafkaListener(topics = {"topic1"},errorHandler = "consumerAwareErrorHandler")
public void onMessage4(ConsumerRecord<?, ?> record) throws Exception {
    throw new Exception("简单消费-模拟异常");
}

// 批量消费也一样，异常处理器的message.getPayload()也可以拿到各条消息的信息
@KafkaListener(topics = "topic1",errorHandler="consumerAwareErrorHandler")
public void onMessage5(List<ConsumerRecord<?, ?>> records) throws Exception {
    System.out.println("批量消费一次...");
    throw new Exception("批量消费-模拟异常");
}

分区分配以及平衡

一个consumer group中有多个consumer组成，一个 topic有多个partition组成，

现在的问题是，到底由哪个consumer来消费哪个partition的数据。

参数名称描述
partition.assignment.strategy消 费 者 分 区 分 配 策 略 ， 默 认 策 略 是 Range + CooperativeSticky。Kafka 可以同时使用多个分区分配策略。可 以 选 择 的 策 略 包 括 ： Range 、 RoundRobin 、 Sticky 、CooperativeSticky
Range

对同一个 topic 里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。

通过 partitions数 / consumer数 来决定每个消费者应该消费几个分区。

如果除不尽，那么前面几个消费者将会多消费 1 个分区。

注意：如果只是针对 1 个 topic 而言，C0消费者多消费1个分区影响不是很大。

但是如果有 N 多个 topic，那么针对每个 topic，消费者 C0都将多消费 1 个分区，topic越多，C0消费的分区会比其他消费者明显多消费 N 个分区。

容易产生数据倾斜！

RoundRobi

RoundRobin 轮询分区策略，是把所有的 partition 和所有的consumer 都列出来，然后按照 hashcode 进行排序，最后通过轮询算法来分配 partition 给到各个消费者。

Sticky

粘性分区：即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可节省开销

Kafka 从 0.11.x 版本开始引入首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化

offset位移

Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始，

consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为**__consumer_offsets**。

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。

key 是 group.id + topic + 分区号，value 就是当前 offset 的值。

每隔一段时间，kafka 内部会对这个 topic 进行compact，也就是每个 group.id+topic+分区号就保留最新数

  • 参数配置

在配置文件 config/consumer.properties 中添加配置

自动提交

自动提交offset的相关参数：

参数影响
enable.auto.commit默认是true，是否开启自动提交offset功能
auto.commit.interval.ms如果设置了 enable.auto.commit 的值为 true，自动提交offset的时间间隔，默认是5s
手动提交

commitSync（同步提交）：必须等待offset提交完毕，再去消费下一批数据。

commitAsync（异步提交） ：发送完提交offset请求后，就开始消费下一批数据了

**同步提交 offset **：有失败重试机制，故更加可靠，但是由于一直等待提交结果，提交的效率比较低

// 1. 创建 kafka 消费者配置类
Properties properties = new Properties();
// 2. 添加配置参数
	....
// 是否自动提交 offset
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
//3. 创建 kafka 消费者
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);
//4. 设置消费主题 形参是列表
consumer.subscribe(Arrays.asList("first"));
//5. 消费数据
while (true){
// 读取消息
  ConsumerRecords<String, String> consumerRecords = 
  consumer.poll(Duration.ofSeconds(1));
  // 输出消息
  for (ConsumerRecord<String, String> consumerRecord : 
    consumerRecords) {
    System.out.println(consumerRecord.value());
  }
  // 同步提交 offset
  consumer.commitSync();
}

异步提交offset

// 其他配置与同步的
// 异步提交 offset
 consumer.commitAsync();
指定Offset 消费

auto.offset.reset = earliest | latest | none 默认是 latest

当 Kafka 中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办？

（1）earliest：自动将偏移量重置为最早的偏移量，–from-beginning

（2）latest（默认值）：自动将偏移量重置为最新偏移量

（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常。

（4）任意指定 offset 位移开始消费

指定时间消费

例如要求按照时间消费前一天的数据

package com.atguigu.kafka.consumer;
import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.serialization.StringDeserializer;
import java.time.Duration;
import java.util.*;
public class CustomConsumerForTime {
	public static void main(String[] args) {
    // 0 配置信息
    Properties properties = new Properties();
    // 连接
    properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
    // key value 反序列化
    properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG,
    	StringDeserializer.class.getName());
		properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,
    	StringDeserializer.class.getName());
    // 消费组id
    properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test2");
    
    // 1 创建一个消费者
    KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
    // 2 订阅一个主题
    ArrayList<String> topics = new ArrayList<>();
    topics.add("first");
    kafkaConsumer.subscribe(topics);
    // 分区信息
    Set<TopicPartition> assignment = new HashSet<>();
    while (assignment.size() == 0) {
      kafkaConsumer.poll(Duration.ofSeconds(1));
 			// 获取消费者分区分配信息（有了分区分配信息才能开始消费）
 			assignment = kafkaConsumer.assignment();
 		}
		HashMap<TopicPartition, Long> timestampToSearch = new HashMap<>();
		// 封装集合存储，每个分区对应一天前的数据
		for (TopicPartition topicPartition : assignment) {
			timestampToSearch.put(topicPartition, 
				System.currentTimeMillis() - 1 * 24 * 3600 * 1000);
 		}
		// 获取从 1 天前开始消费的每个分区的 offset
  	Map<TopicPartition, OffsetAndTimestamp> offsets = 
      kafkaConsumer.offsetsForTimes(timestampToSearch);
		// 遍历每个分区，对每个分区设置消费时间。
 		for (TopicPartition topicPartition : assignment) {
 			OffsetAndTimestamp offsetAndTimestamp = offsets.get(topicPartition);
 			// 根据时间指定开始消费的位置
 			if (offsetAndTimestamp != null){
 				kafkaConsumer.seek(topicPartition, offsetAndTimestamp.offset());
			}
 		}  
  	// 3 消费该主题数据
    while (true) {
      ConsumerRecords<String, String> consumerRecords = 
        kafkaConsumer.poll(Duration.ofSeconds(1));
      for (ConsumerRecord<String, String> consumerRecord : 
           consumerRecords) {
        System.out.println(consumerRecord);
      }
    }
  }
}

Kafka-Eagle监控

Kafka-Eagle 框架可以监控 Kafka 集群的整体运行情况，在生产环境中经常使用。

可以在浏览器打开 localhost:8084 登录页面查看监控数据

Kafka-Eagle 的安装依赖于 MySQL，MySQL 主要用来存储可视化展示的数据

官网：https://www.kafka-eagle.org/

上传压缩包 kafka-eagle-bin-2.0.8.tar.gz 到集群 **/opt/**software 目录

在这里插入图片描述

Kafka-Kraft 模式

Kafka 现有架构，元数据在 zookeeper 中，运行时动态选举 controller，由controller 进行 Kafka 集群管理。

kraft 模式架构（实验性），不再依赖 zookeeper 集群，而是用三台 controller 节点代替 zookeeper，元数据保存在 controller 中，由 controller 直接进行 Kafka 集群管理

好处有以下几个：

  1. Kafka 不再依赖外部框架，而是能够独立运行；

  2. controller 管理集群时，不再需要从 zookeeper 中先读取数据，集群性能上升；

  3. 由于不依赖 zookeeper，集群扩展时不再受到 zookeeper 读写能力限制；

  4. controller 不再动态选举，而是由配置文件规定。这样我们可以有针对性的加强

  5. controller 节点的配置，而不是像以前一样对随机 controller 节点的高负载束手无策。

Spring Boot继承kafka

AdminClient API：允许管理和检测Topic、broker以及其它Kafka对象

Producer API：发布消息到1个或多个topic

Consumer API：订阅一个或多个topic,并处理产生的消息

Streams API：高效地将输入流转换到输出流

Connector API：从一些源系统或应用程序中拉取数据到kafka

@kafkaListener

直接依赖

<!-- kafka -->
		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka_2.13</artifactId>
			<version>2.7.0</version>
		</dependency>
		
		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
			<version>2.7.0</version>
		</dependency>
		
		<dependency>
			<groupId>io.mosip</groupId>
			<artifactId>kafka-admin-client</artifactId>
			<version>1.2.0</version>
			<exclusions>
				<exclusion>
					<groupId>org.apache.kafka</groupId>
					<artifactId>kafka-clients</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-server-common</artifactId>
			<version>3.1.0</version>
			<exclusions>
				<exclusion>
					<groupId>org.apache.kafka</groupId>
					<artifactId>kafka-clients</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

adminClient

The AdminClient API 直接管理检查topic，brokers，acls等

创建Topic
createTopics(Collection<NewTopic> newTopics)
删除Topic：
deleteTopics(Collection<String> topics)
罗列所有Topic
listTopics()
查询Topic
describeTopics(Collection<String> topicNames)
查询集群信息
describeCluster()
查询ACL信息：
describeAcls(AclBindingFilter filter)
创建ACL信息：
createAcls(Collection<AclBinding> acls)
删除ACL信息：
deleteAcls(Collection<AclBindingFilter> filters)
查询配置信息：
describeConfigs(Collection<ConfigResource> resources)
修改配置信息：
alterConfigs(Map<ConfigResource, Config> configs)
修改副本的日志目录：
alterReplicaLogDirs(Map<TopicPartitionReplica, String> replicaAssignment)
查询节点的日志目录信息：
describeLogDirs(Collection<Integer> brokers)
查询副本的日志目录信息：
describeReplicaLogDirs(Collection<TopicPartitionReplica> replicas)
增加分区：
createPartitions(Map<String, NewPartitions> newPartitions)

简单使用adminclient创建topic实例

private static final String NEW_TOPIC = "topic-test2";
private static final String brokerUrl = "localhost:9092";
private static final Integer numPartition = 4;
private static final short replication = 1;
private static AdminClient adminClient;

@BeforeClass
public static void beforeClass(){
  Properties properties = new Properties();
  properties.put(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, brokerUrl);
  adminClient = AdminClient.create(properties);
}

@AfterClass
public static void afterClass(){
  log.info("Kafka-Admin-client开始被关闭");
  adminClient.close();
  log.info("Kafka-Admin-client已经被关闭了");
}

@Test
public void createTopics() {
  /*
  	NewTopic newTopic = new NewTopic(NEW_TOPIC, numPartition, replication);
    Collection<NewTopic> newTopicList = new ArrayList<>();
    newTopicList.add(newTopic);
  	Arrays.asList(new NewTopic(topic, numPartition, replication))
  	CreateTopicsResult topics = adminClient.createTopics(newTopicList);
  	*/
  CreateTopicsResult topics = kafkaAdminClient.createTopics(Arrays.asList(
    new NewTopic(NEW_TOPIC, numPartition, replication)));
  /*
  KafkaFuture<Void> future = topics.all();
  while (!kafkaFuture.isDone()){
    try {
      Thread.sleep(1000L);
    } catch (InterruptedException e) {
      log.error("被线程中断信号干扰导致停止睡眠");
      e.printStackTrace();
    }
  }
  future.get();
  */
  log.debug("创建topic的请求成功");
}

springboot整合zookeeper

curator是Netflix公司开源的一个 zookeeper客户端，后捐献给 apache，curator框架在zookeeper原生API接口上进行了包装，解决了很多zooKeeper客户端非常底层的细节开发。

提供zooKeeper各种应用场景(比如:分布式锁服务、集群领导选举、共享计数器、缓存机制、分布式队列等的抽象封装，实现了Fluent风格的APl接口，是最好用，最流行的zookeeper的客户端

  • 原生zookeeperAPI的不足

​ 连接对象异步创建，需要开发人员自行编码等待
​ 连接没有自动重连超时机制
​ watcher一次注册生效一次
​ 不支持递归创建树形节点

  • curator特点

​ 解决session会话超时重连
​ watcher反复注册
​ 简化开发api
​ 遵循Fluent风格API

引入依赖

<!-- zookeeper -->
<dependency>
  <groupId>org.apache.zookeeper</groupId>
  <artifactId>zookeeper</artifactId>
  <version>3.6.2</version>
</dependency>
<dependency>
  <groupId>org.apache.curator</groupId>
  <artifactId>curator-framework</artifactId>
  <version>4.0.1</version>
</dependency>
<dependency>
  <groupId>org.apache.curator</groupId>
  <artifactId>curator-recipes</artifactId>
  <version>4.0.1</version>
</dependency>
丶di
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
消息队列Kafka简介基本用法
05-06
消息队列kafka的基本用法与介绍
kafka学习（六）：kafka应用场景
weixin_40482816的博客
11-24 3922
消息队列中间件是分布式系统中重要的组件，主要解决，，等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。
kafka-稳定性-控制器
小城我家
11-14 147
控制器 afka集群包含若干个broker，broker.id指定broker的编号，编号不要重复。 Kafka集群上创建的主题，包含若干个分区。 每个分区包含若干个副本，副本因子包括了Follower副本和Leader副本。 副本又分为ISR（同步副本分区）和OSR（非同步副本分区） 控制器就是一个broker 控制器除了一般broker的功能，还负责Leader分区的选举 broker选举 集群里第一个启动的broker在Zookeeper中创建临时节点 /controller 。 其他broker在
Kafka副本管理—— 为何去掉replica.lag.max.messages参数
weixin_33711641的博客
09-24 209
　　今天查看Kafka 0.10.0的官方文档，发现了这样一句话：Configuration parameter replica.lag.max.messages was removed. Partition leaders will no longer consider the number of lagging messages when deciding which replicas ar...
kafka配置文件Leader,Replicas参数
weixin_44603464的博客
07-13 676
【代码】kafka配置文件Leader,Replicas参数。
KafkaBroker的重要参数
feizuiku0116的博客
06-22 383
ISR中，如果Follower长时间未向Leader发送消息请求或同步数据，则该Follower将被提出ISR，该时间阈值，默认30s默认是true，自动Leader Partition平衡默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡默认值300s，检查leader负载是否平衡的间隔时间kafka中log日志是分成一块块存储的，此配置是指log日志划分成块的大小，默认值1G默认4kb，kafak里面每当写入了4kb大小的日志
Kafka的ISR收缩机制
959
02-18 1651
ISR什么时候收缩 ISR什么时候扩展 ISR的传播机制 Broker宕机之后怎么ISR的收缩？ Kafka在启动的时候,会启动一个副本管理器ReplicaManager,这个副本管理器会启动几个定时任务。 ISR过期定时任务isr-expiration,每隔replica.lag.time.max.ms/2毫秒就执行一次。 ISR变更的传播定时任务isr-change-propagation,每隔2500毫秒就执行一次。 replica.lag.time.max.ms : 如果一个follower.
Kafka学习笔记（六）· 稳定性
一个到老才知道分享的人的博客
12-21 667
目录七、稳定性1、幂等性2、事务3、控制器4、可靠性保证5、一致性保证6、消息重复的场景及解决方案1、生产者端重复2、消费者端重复1、根本原因7、_consumer_offsets1、何时创建2、解析分区 七、稳定性 kafka的消息传输保障机制非常直观。当producer向broker发送消息时，一旦这条消息被commit，由于副本机制（replication）的存在，他就不会丢失。但是如果producer发送数据给broker后，遇到的网络问题而造成通信中断，那producer就无法判断该条消息是否已经
Kafka深度解析
雲的博客
07-22 2358
背景介绍Kafka简介 [size=16.7999992370605px]　　Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，并保证即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafka Server间的消息分区，
【无标题】Kafka副本管理—— 为何去掉replica.lag.max.messages参数
九师兄
01-26 476
1.概述 转载：Kafka副本管理—— 为何去掉replica.lag.max.messages参数 今天查看Kafka 0.10.0的官方文档，发现了这样一句话：Configuration parameter replica.lag.max.messages was removed. Partition leaders will no longer consider the number of lagging messages when deciding which replicas are in syn
KAFKA高级应用
qq_35623417的博客
01-05 1158
一些kafka的基础使用以及说明请参考上一篇文章kafka的基础入门。这篇文章主要是写kafka的一些高级特性、存储结构以及原理。
企业级消息队列Kafka视频教程
10-21
细致简介了消息队列在大数据的应用场景、Kafka集群搭建、Kafka操作，基准测试、架构、编程、结合Kafka Eagle简介原理等 课程亮点 1，知识体系完备，从小白到大神各阶段读者均能学有所获。 2，生动形象，化繁为简，...
消息队列Kafka高可靠性原理深度解读
02-25
Kafka凭借着自身的优势，越来越受到互联网企业的青睐，唯品会也采用Kafka作为其内部核心消息引擎之一。Kafka作为一个商业级消息中间件，消息可靠性的重要性可想而知。如何确保消息的精确传输？如何确保消息的准确...
Kafka消息队列
01-07
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量...
Kafka 3.x.x 入门到精通（04）——对标尚硅谷Kafka教程
最新发布
这里有一只小马吖
04-26 827
Kafka是一个由Scala和Java语言开发的，经典高吞吐量的分布式消息发布和订阅系统，也是大数据技术领域中用作数据交换的核心组件之一。以高吞吐，低延迟，高伸缩，高可靠性，高并发，且社区活跃度高等特性，从而备受广大技术组织的喜爱。
深入理解Java消息中间件-Apache Kafka
u011532237的博客
04-21 1412
Apache Kafka是一个开源的分布式事件流平台，由LinkedIn创建，并于2011年贡献给了Apache软件基金会。它设计用来高效处理实时数据流和大数据，通过发布-订阅的消息系统提供高吞吐量、持久存储、流数据处理等功能。
3节点ubuntu24.04服务器docker-compose方式部署高可用elk+kafka日志系统并接入nginx日志
qq_41905051的博客
04-23 1011
3节点ubuntu24.04服务器docker-compose方式部署高可用elk+kafka日志系统并接入nginx日志
Kafka---总结篇
gochenguowei的博客
04-25 946
Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。确定好消息的topic+partition后，直接发送给对应leader副本所在的broker。LSO 的值等于事务中第一条消息的位置(firstUnstableOffset，如上图所示)，对已完成的事务而言，它的值同 HW 相同。其中轮询策略是默认的分区策略，而随机策略则是较老版本的分区策略，不过由于其分配的均衡性不如轮询策略，故而后来改成了轮询策略为默认策略。
手拉手安装Kafka2.13发送和消费消息
weixin_47268883的博客
04-22 1076
手拉手安装Kafka2.13发送和消费消息
java消息队列kafka的应用场景
01-04
Kafka是一个高吞吐量的分布式消息队列系统，它具有广泛的应用场景。以下是Java消息队列Kafka的一些常见应用场景： 1. 实时日志收集和分析：Kafka可以用于收集和存储大规模分布式系统的日志数据。通过将日志数据发送到Kafka集群，可以实时地将日志数据传输到各种消费者，如实时监控系统、日志分析系统等。 2. 流式处理：Kafka可以作为流式处理平台的基础，用于构建实时数据处理和分析系统。通过将数据流发送到Kafka主题，可以实现实时的数据处理和分析，如实时计算、实时推荐等。 3. 消息队列：Kafka作为消息队列，可以用于解耦和缓冲不同组件之间的通信。生产者将消息发送到Kafka，消费者从Kafka订阅并处理这些消息，实现了不同组件之间的解耦和异步通信。 4. 大数据集成：Kafka可以与其他大数据技术集成，如Hadoop、Spark等。通过将数据从这些系统发送到Kafka，可以实现数据的实时传输和处理。 5. 数据备份和恢复：Kafka提供了数据持久化的功能，可以将数据写入磁盘并进行备份。这使得Kafka可以用于数据的持久化存储和故障恢复。 6. 事件驱动架构：Kafka可以作为事件驱动架构的基础，于构建高可扩展的微服务架构。通过将事件发送到Kafka，不同的微服务可以订阅并处理这些事件，实现了松耦合和可扩展的架构。 以上是Java消息队列Kafka的一些常见应用场景。根据具体的业务需求和系统架构，还可以有其他更多的应用场景。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值