Kafka3.x重点归纳2

第1章 Kafka概述

1.1 定义

1.2 传统消息队列的应用场景

1. 传统的消费队列的主要应用场景有：缓存/削峰、解耦、异步通信。
   
   

1.3 消息队列的两种模式

消息队列主要分为两种模式：点对点模式和发布/订阅模式。

1.4 Kafka基础架构

1）Producer ：消息生产者，就是向kafka broker发消息的客户端；
2）Consumer ：消息消费者，向kafka broker取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个topic下的一个分区只能被一个消费者组内的一个消费者所消费；消费者组之间互不影响。消费者组是逻辑上的一个订阅者。
4）Broker ：一台kafka服务器就是一个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。

第2章 Kafka命令行操作

2.1 主题命令行操作

1. 查看操作主题命令需要的参数

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh

2. 重要的参数如下

参数	描述
–bootstrap-server	连接kafka Broker主机名称和端口号
–topic	操作的topic名称
–create	创建主题
–delete	删除主题
–alter	修改主题
–list	查看所有主题
–describe	查看主题详细描述
–partitions	设置主题分区数
–replication-factor	设置主题分区副本
–config	更新系统默认的配置

3. 查看当前服务器中的所有topic

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --list

4. 创建一个主题名为first的topic

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --replication-factor 2 --partitions 1 --topic first

5. 查看Topic的详情

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic first

Topic: first    TopicId: EVV4qHcSR_q0O8YyD32gFg PartitionCount: 1       ReplicationFactor: 3    Configs: segment.bytes=1073741824
        Topic: first    Partition: 0    Leader: 102     Replicas: 102,103,104   Isr: 102,103,104

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

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --alter --topic first --partitions 3

7. 再次查看Topic的详情

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic first

Topic: first    TopicId: EVV4qHcSR_q0O8YyD32gFg PartitionCount: 3       ReplicationFactor: 3    Configs: segment.bytes=1073741824
        Topic: first    Partition: 0    Leader: 102     Replicas: 102,103,104   Isr: 102,103,104
        Topic: first    Partition: 1    Leader: 103     Replicas: 103,104,102   Isr: 103,104,102
        Topic: first    Partition: 2    Leader: 104     Replicas: 104,102,103   Isr: 104,102,103

8. 删除topic

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --delete --topic first

2.2 生产者命令行操作

1. 查看命令行生产者的参数

[chenyunde@hadoop102 kafka]$ bin/kafka-console-producer.sh

2. 重要的参数如下：

参数	描述
–bootstrap-server	连接kafka Broker主机名称和端口号
–topic	操作的topic名称

3. 生产消息

[chenyunde@hadoop102 kafka]$ bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first

hello world
aaa  aaa

2.3 消费者命令行操作

1. 查看命令行消费者的参数

[chenyunde@hadoop102 kafka]$ bin/kafka-console-consumer.sh

2. 重要的参数如下：

参数	描述
–bootstrap-server	连接kafka Broker主机名称和端口号
–topic	操作的topic名称
–from-beginning	从头开始消费
–group	指定消费者组名称

3. 消费消息

[chenyunde@hadoop102 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

4. 从头开始消费

//将kafka的历史数据都拿过来消费
[chenyunde@hadoop102 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --from-beginning --topic first

思考：再次查看当前kafka中的topic列表，发现了什么？为什么

第3章 Kafka生产者

3.1 生产者消息发送流程

3.1.1 发送原理

Kafka的Producer发送消息采用的是异步发送的方式。
在消息发送的过程中，涉及到了两个线程:main线程和Sender线程，以及一个线程共享变量:RecordAccumulator。
①main线程中创建了一个双端队列RecordAccumulator，将消息发送给RecordAccumulator。
②Sender线程不断从RecordAccumulator中拉取消息发送到Kafka broker。

图解

1. 希望将外部接收来的数据传送到kafka集群
2. 创建一个Kafka Producer对象，有了这个对象可以将数据发到kafka集群
3. 该对象调用send方法
4. 数据经过拦截器，对数据进行加工(可以选择不用，生产环境用的不多，flume拦截器配置使用起来更简单一些)
5. 数据继续往下传，经过序列化器(Java自带多序列化器太重)
6. 数据继续往下传，走到分区器，分区器来按照规则判断分区让数据进入到哪个RecordAccumulator对象的队列中(一个分区一个队列，这一步都是在内存中完成的，默认大小是32m，每一次批次大小是16k)
7. sender线程是将队列中的数据读取发往kafka集群(batch.size：只有数据累计到batch.size之后，sender才会发送数据。默认16k；linger.ms：如果数据迟迟未达到batch.size，sender等待linger.ms设置的时间到了之后就会发送数据。单位ms，默认值是0ms，表示没有延迟)
8. NetworkClient里InFlightRequests默认最多可以缓存每个节点的五个未应答的请求
9. selector打通后，队列向leader发送数据，leader向follower同步数据
10. kafka应答级别(如果设置成0:生产者发送过来的数据，不需要等数据落盘应答；ack=1:生产者发送过来的数据，Leader收到数据后应答，即使副本没有同步完成；ack=-1或者all：生产者发送过来的数据，Leader和ISR队列里面的所有节点收起数据后应答。-1和all等价。后面会详细讲解)
11. ack应答如果返回成功，清理这次请求和对应分区数据，应答失败则进行重试，重试的次数是int的最大值(直到成功为止，可修改)

3.1.2 生产者重要参数列表

参数名称	描述
bootstrap.servers	生产者连接集群所需的broker地址清单。可以设置1个或者多个，中间用逗号隔开。生产者从给定的broker里查找到其他broker信息。
key.serializer、 value.serializer	指定发送消息的key和value的序列化类型。要写全类名。
buffer.memory	RecordAccumulator缓冲区总大小，默认32m。
batch.size	缓冲区一批数据最大值，默认16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。
linger.ms	如果数据迟迟未达到batch.size，sender等待linger.time之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。生产环境建议该值大小为5-100ms之间。
acks	0：生产者发送过来的数据，不需要等数据落盘应答。1：生产者发送过来的数据，Leader数据落盘后应答。-1（all）：生产者发送过来的数据，Leader和isr队列里面的所有节点数据都落盘后应答。默认值是-1
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。

3.2 异步发送API

3.2.1 普通异步发送

1. 需求：创建Kafka生产者，采用异步的方式发送到Kafka broker
2. 异步发送流程如下：

3. 代码编写
   1）创建工程kafka-demo
   2）导入依赖

<dependencies>
        <dependency>
            <groupId>org.apache.kafkagroupId>
            <artifactId>kafka-clientsartifactId>
            <version>3.0.0version>
        dependency>
dependencies>

3）创建包名：com.chenyunde.kafka.producer
4）编写代码：不带回调函数的API

package com.chenyunde.kafka.producer;

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.common.serialization.StringSerializer;
import java.util.Properties;

public class CustomProducer {
    public static void main(String[] args) throws InterruptedException {
        // 1. 创建kafka生产者的配置对象
        Properties properties = new Properties();

        // 2. 给kafka配置对象添加配置信息
        //properties.put("bootstrap.servers","hadoop102:9092");
		properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092")
        // key,value序列化
        //properties.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());
        //properties.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,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));
        }

        // 5. 关闭资源
        kafkaProducer.close();
    }
} 

5）测试：
在hadoop102上开启kafka消费者

[chenyunde@hadoop104 kafka]$ sbin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

在IDEA中执行上述代码，观察hadoop102消费者输出

[chenyunde@hadoop104 kafka]$ sbin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

kafka0
kafka1
kafka2
kafka3

3.2.2 带回调函数的异步发送

1. 回调函数会在producer收到ack时调用，为异步调用。
   该方法有两个参数分别是RecordMetadata（元数据信息）和Exception（异常信息）。
   ·如果Exception为null，说明消息发送成功，
   ·如果Exception不为null，说明消息发送失败。
2. 带回调函数的异步调用发送流程
   
   注意：消息发送失败会自动重试，不需要我们在回调函数中手动重试。

3.3 同步发送API

1. 同步发送的意思就是，一条消息发送之后，会阻塞当前线程，直至返回ack。
   由于send方法返回的是一个Future对象，根据Futrue对象的特点，我们也可以实现同步发送的效果，只需在调用Future对象的get方发即可。
2. 同步发送流程示意图如下：
   

3.4 生产者分区

3.4.1 分区的原因

3.4.2 生产者分区策略

kafka分区的好处

1. 便于合理使用存储资源，每个Partition在一个Broker上存储，可以把海量的数据按照分区切割成一块一块数据存储在多台Broker上。合理控制分区的任务，可以实现负载均衡的效果。
2. 提高并行度，生产者可以以分区为单位发送数据；消费者可以以分区为单位进行消费数据

1．默认分区器

DefaultPartitioner The default partitioning strategy: ·If a partition
is specified in the record, use it ·If no partition is specified but a
key is present choose a partition based on a hash of the key ·If no
partition or key is present choose the sticky partition that changes
when the batch is full. public class DefaultPartitioner implements
Partitioner { … … }

2．使用：
1） 我们需要将producer发送的数据封装成一个ProducerRecord对象。
2） 上述的分区策略，我们在ProducerRecord对象中进行配置。

3.4.3 自定义分区器

1. 生产环境中，我们往往需要更加自由的分区需求，我们可以自定义分区器。
2. 需求：在上面的根据key分区案例中，我们发现与我们知道的hash分区结果不同。那么我们就实现一个。
   3．实现步骤：
   ① 定义类，实现Partitioner接口
   ② 重写partition()方法
3. 代码实现：

package com.chenyunde.kafka.partitioner;

import org.apache.kafka.clients.producer.Partitioner;
import org.apache.kafka.common.Cluster;
import java.util.Map;

/**
 * @author leon
 * @create 2020-12-11 10:43
 * 1. 实现接口Partitioner
 * 2. 实现3个方法:partition,close,configure
 * 3. 编写partition方法,返回分区号
 */
public class MyPartitioner implements Partitioner {
    /**
    *  分区方法
    **/
    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
       // 1. 获取key
        String keyStr = key.toString();
        // 2. 创建分区号，返回的结果
        int partNum;
        // 3. 计算key的hash值
        int keyStrHash = keyStr.hashCode();
        // 4. 获取topic的分区个数
        int partitionNumber = cluster.partitionCountForTopic(topic);
        // 5. 计算分区号
        partNum = Math.abs(keyStrHash) % partitionNumber;
        // 4. 返回分区号
        return partNum;
    }

    // 关闭资源
    @Override
    public void close() {
    }

    // 配置方法
    @Override
    public void configure(Map<String, ?> configs) {
    }
}

5. 测试
   在生产者代码中，通过配置对象，添加自定义分区器
   // 添加自定义分区器

properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG," com.chenyunde.kafka.partitioner.MyPartitioner ");

在hadoop102上启动kafka消费者

[chenyunde@hadoop102 kafka]$ sbin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

在IDEA中观察回调信息

消息：chenyunde 2, 主题：first->分区：2
消息：chenyunde 5, 主题：first->分区：2
消息：chenyunde 8, 主题：first->分区：2
消息：chenyunde 1, 主题：first->分区：1
消息：chenyunde 4, 主题：first->分区：1
消息：chenyunde 7, 主题：first->分区：1
消息：chenyunde 10, 主题：first->分区：1
消息：chenyunde 3, 主题：first->分区：0
消息：chenyunde 6, 主题：first->分区：0
消息：chenyunde 9, 主题：first->分区：0

3.5 生产经验——生产者如何提高吞吐量

3.5.1 吞吐量

3.5.2 案例实操

1. 编写代码：

package com.chenyunde.kafka.producer;

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;

public class CustomProducerParameters {

    public static void main(String[] args) throws InterruptedException {

        // 1. 创建kafka生产者的配置对象
        Properties properties = new Properties();

        // 2. 给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");

        // batch.size：批次大小，默认16K
        properties.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);

        // linger.ms：等待时间，默认0
        properties.put(ProducerConfig.LINGER_MS_CONFIG, 1);

        // 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");

        // 3. 创建kafka生产者对象
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);

        // 4. 调用send方法,发送消息
        for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("first","chenyunde" + i));
        }

        // 5. 关闭资源
        kafkaProducer.close();
    }
}

2. 测试：
   ① 在hadoop102上开启kafka消费者

[chenyunde@hadoop102 kafka]$ sbin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

② 在IDEA中执行代码，观察hadoop102上的消费者消费情况
[chenyunde@hadoop102 kafka]$ sbin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first
chenyunde
chenyunde
chenyunde
……

3.6 生产经验——数据可靠性

3.6.1 ack应答机制

图解1

1. ack=0:生产者将数据发给Leader，如果数据还在内存中，此时Leader挂掉还未来得及和Follower进行同步，数据会丢失，生产环境中ack=0使用的较少
2. ack=1:生产者发送来的数据，Leader落盘之后，把数据持久化到磁盘就给生产者应答，即使Follower没有同步完成都可以；风险：应答完成后，还没有开始同步副本时Leader挂掉，新的Leader被选举产生，新的Leader不会收到Hello的信息，因为生产者已经认为发送成功了；虽然有丢数据的可能但是比ack=0要稍微好一些
3. ack=-1:生产者发送过来的数据，Leader收到数据，Follower会主动来拉数据，当Follower都拉其数据后，Leader给生产者进行应答，弊端：如果有个Follower出现故障会导致Leader一直无法应答–>整个集群瘫痪

总结：
ack应答级别
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

acks=0	这一操作提供了一个最低的延迟，partition的leader副本接收到消息还没有写入磁盘就已经返回ack，当leader故障时有可能丢失数据；
acks=1	partition的leader副本落盘后返回ack，如果在follower副本同步数据之前leader故障，那么将会丢失数据；
acks-1	(all) partition的leader和follower副本全部落盘成功后才返回ack。但是如果在follower副本同步完成后，leader副本所在节点发送ack之前，leader副本发生故障，那么会造成数据重复。

3.6.2 ack应答级别

图解2

解决上述弊端：kafka提供了ISR队列解决方案①Leader维护了一个动态的in-sync replica set (ISR)和leader保持同步的follower集合。
②当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。
③如果follower长时间（replica.lag.time.max.ms）未向leader同步数据，则该follower将被踢出ISR。
Leader发生故障之后，就会从ISR中选举新的leader。
思考：数据可靠性分析：如果分区副本设置为1，或者ISR里应答的最小副本数量（min.insync.replicas默认为1）设置为1，和ack=1的效果时一样的，仍然有丢数据的风险（leader:0,isr=0）

真正做到数据完全可靠的条件=ACK级别设置为-1+分区副本大于等于2+ISR里应答的最小副本数量大于等于2

3.6.3 ack应答机制总结

数据重复分析，在Leader同步给所有Follower数据后挂掉了，ack并没有成功发送到生产者，此时选举出了一个新的Leader，新的Leader又接收了一份数据，导致数据重复，这种概率虽然低但是不能排除没有，在后续章节会解决

3.6.4 案例实操

代码编写

package com.chenyunde.kafka.producer;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;

public class CustomProducerAck {
    public static void main(String[] args) throws InterruptedException {

        // 1. 创建kafka生产者的配置对象
        Properties properties = new Properties();

        // 2. 给kafka配置对象添加配置信息：bootstrap.servers
        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, StringSerializer.class.getName());

        // 设置acks
        properties.put(ProducerConfig.ACKS_CONFIG, "all");

        // 重试次数retries，默认是int最大值，2147483647
        properties.put(ProducerConfig.RETRIES_CONFIG, 3);

        // 3. 创建kafka生产者对象
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);

        // 4. 调用send方法,发送消息
        for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("first","chenyunde " + i));
        }

        // 5. 关闭资源
        kafkaProducer.close();
    }
}

3.7 生产经验——数据去重

3.7.1 数据传递语义

3.7.2 幂等性

1. 幂等性原理：

2. 开启幂等性

在prudocer的配置对象中，添加参数enable.idempotence,参数值默认为true，设置为false就关闭了。

3.7.3 生产者事务

1. kafka事务原理
   

图解

1. 生产者向事务协调器请求pid(给幂等性用，事务的底层就是幂等性)
2. 事务协调器返回pid
3. 生产者发送数据往Leader
4. 事务协调器发送commit请求
5. 请求的消息会持久化到存储事务信息的特殊主题中（方便后续回滚）
6. 事务协调器告诉生产者已经持久化完毕，返回成功
7. 事务协调器会给Leader节点发送一个commit请求，判断这个生产者传来的数据有没有真正的写完在Leader内
8. 如果判断是true，这个事务返回成功
9. 事务协调器将持久化事务成功信息

事务代码流程（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;

3.8 生产经验——数据有序

3.9 生产经验——数据乱序

图解

• 在生产端会对每个broker节点最多缓存5个请求，假设有两个broker节点就会有两个队列，每个队列里最多放五个没有应答的请求
• 乱序的可能原因，队列发送第一个和第二个请求是kafka集群正常应答，但是第三个请求不成功，会不断的进行重试，这时候第四个请求发送到kafka集群成功，此时的顺序是124，导致了数据的乱序
• kafka在1.x版本之前保证数据单分区有序的条件是设置max.in.flight.requests.per.connection=1(不需要考虑是否开启幂等性)
• 在1.x及以后的版本保证数据单分区有序的条件：如果未开启幂等性——max.in.flight.requests.per.connection=1;如果开启幂等性——max.in.flight.requests.per.connection需要设置成小于等于5
• 原因说明：因为在kafka1.x以后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据，故无论如何，都可以保证最近5个request的数据都是有序的
• 幂等性条件第一个是Pid，第二个是分区，第三个是序列号，这里序列号是单调递增的，kafka服务端缓存了producer最近发来的五个request元数据，按照上面的例子是（1，2，4，5，3），1，2数据进入的时候与序列号对应的上可以落盘，下一个读的是4数据，与序列号不一致只能在内存中放着不能落盘，5与4一样，不能落盘，直到等到3来到，服务端重新排序（1，2，3，4，5）

第4章 Kafka Broker

4.1 Kafka Broker 工作流程

4.1.1 Zookeeper存储的Kafka的信息

1. 查看zookeeper中的kafka节点所存储的信息

启动Zookeeper客户端

[chenyunde@hadoop104 zookeeper-3.5.7]$ bin/zkCli.sh

通过ls命令列出kafka节点内容

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

2. zookeeper 中存储的kafka信息
   

4.1.2 Kafka Broker总体工作流程

1. Kafka Broker工作流程图示
   

图解

1. 每台kafka节点启动后，都会向zookeeper注册（/brokers/ids[0,1,2]），启动一个注册一个
2. 都注册完后开始选择Controller节点，broker里面每个都对应有一个Controller谁先注册，谁说了算
3. 由选举出来的Controller监听对应的brokers节点变化，/brokers/ids这个节点下有任何broker的变化都能看到
   AR：Kafka分区中的所有副本统称
4. Controller决定Leader选举——选举规则：在isr中存活为前提，按照AR中排在前面的优先。例如ar[1,0,2],isr[1,0,2],那么leader就会按照1,0,2轮询
5. 选举出来broker1为Leader之后，Controller将节点信息上传到ZK——把leader信息和isr信息都会写到此节点下进行备份

/brokers/topics/first/partitions/0/state
“leader”:1,“isr”:[1,0,2]

6. 接下来其他controller节点会从ZK同步相关信息（拉取节点信息），防止leader挂掉，随时准备上位
7. 接下来就是kafka生产者往集群发送数据，Leader与Follower同步信息，底层存储形式是log（虚拟名称，存的是Segment，大小为1G），为了加快查询速度，采用了index索引的方式进行检索，.log就是这1G的size
8. 生产环境中，如果broker1的leader挂了，ZK中的节点，controller就能监控到这个节点的变化，然后从ZK中拉取leader信息和isr信息，进行重新的leader选举（在isr中存活为前提，按照AR中排前面的优先）
9. 更新Leader以及ISR的变化

4.1.3 Broker重要参数

参数名称	描述
replica.lag.time.max.ms	ISR中的Follower超过该事件阈值(默认30s)未向Leader发送同步数据，则该Follower将被踢出ISR。
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.bytes	Kafka中log日志是分成一块块存储的，此配置是指log日志划分 成块的大小，默认值1G。
log.index.interval.bytes	默认4kb，kafka里面每当写入了4kb大小的日志（.log），然后就往index文件里面记录一个索引。
log.retention.hours	Kafka中数据保存的时间，默认7天。
log.retention.minutes	Kafka中数据保存的时间，分钟级别，默认关闭。
log.retention.ms	Kafka中数据保存的时间，毫秒级别，默认关闭。
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	强制页缓存刷写到磁盘的条数，默认是Max(long) (9223372036854775807)。一般交给系统管理。
log.flush.interval.ms	每隔多久，刷数据到磁盘，默认是null。一般不建议修改，交给系统自己管理。

4.2 生产经验——节点服役和退役

4.2.1 服役新节点

1）新节点准备
（1）关闭 hadoop104，并右键执行克隆操作。 （2）开启 hadoop105，并修改 IP 地址。

[root@hadoop104 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ens33

DEVICE=ens33
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
NAME="ens33"
IPADDR=192.168.10.105
PREFIX=24
GATEWAY=192.168.10.2
DNS1=192.168.10.2

（3）在 hadoop105 上，修改主机名称为 hadoop105。

[root@hadoop104 ~]# vim /etc/hostname

hadoop105
（4）重新启动 hadoop104、hadoop105。 （5）修改 haodoop105 中 kafka 的 broker.id 为 3。 （6）删除 hadoop105 中 kafka 下的 datas 和 logs。

[chenyunde@hadoop105 kafka]$ rm -rf datas/* logs/*

（7）启动 hadoop102、hadoop103、hadoop104 上的 kafka 集群。

[chenyunde@hadoop102 ~]$ zk.sh start

[chenyunde@hadoop102 ~]$ kf.sh start

（8）单独启动 hadoop105 中的 kafka。

[chenyunde@hadoop105 kafka]$ bin/kafka-server-start.sh - daemon
./config/server.properties

4.2.2 执行负载均衡操作

(1)创建一个要均衡的主题

[chenyunde@hadoop102 kafka]$ vim topics-to-move.json

{
	"topics": [
		{"topic":"first"}
	],
	"version":1
}

(2)生成一个负载均衡计划

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --
bootstrap-server hadoop102:9092 --topics-to-move-json-file 
topics-to-move.json --broker-list "0,1,2,3" --generate

Current partition replica assignment
{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[0,2,1],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[2,1,0],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[1,0,2],"log_dirs":["any","
any","any"]}]}
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[2,3,0],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[0,1,2],"log_dirs":["any","
any","any"]}]}

（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2、broker3 中）。

[chenyunde@hadoop102 kafka]$ vim increase-replication-factor.json

输入如下内容：

{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[2,3,0],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[0,1,2],"log_dirs":["any","
any","any"]}]}

（4）执行副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --execute

（5）验证副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --verify

Status of partition reassignment:
Reassignment of partition first-0 is complete.
Reassignment of partition first-1 is complete.
Reassignment of partition first-2 is complete.
Clearing broker-level throttles on brokers 0,1,2,3
Clearing topic-level throttles on topic first

4.2.3 退役旧节点

1）执行负载均衡操作
先按照退役一台节点，生成执行计划，然后按照服役时操作流程执行负载均衡。 （1）创建一个要均衡的主题。

[chenyunde@hadoop102 kafka]$ vim topics-to-move.json

{
"topics": [
{"topic": "first"}
],
"version": 1
} 

（2）创建执行计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --topics-to-move-json-file
topics-to-move.json --broker-list “0,1,2” --generate

Current partition replica assignment
{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[3,1,2],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[0,2,3],"log_dirs":["any","
any","any"]}]}
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[1,2,0],"log_dirs":["any","
any","any"]}]}

（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2 中）。

[chenyunde@hadoop102 kafka]$ vim increase-replication-factor.json

{"version":1,"partitions":[{"topic":"first","partition":0,"replic
as":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","par
tition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"to
pic":"first","partition":2,"replicas":[1,2,0],"log_dirs":["any","
any","any"]}]}

（4）执行副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --execute

（5）验证副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --verify

Status of partition reassignment:
Reassignment of partition first-0 is complete.
Reassignment of partition first-1 is complete.
Reassignment of partition first-2 is complete.
Clearing broker-level throttles on brokers 0,1,2,3
Clearing topic-level throttles on topic first

2）执行停止命令
在 hadoop105 上执行停止命令即可。

[chenyunde@hadoop105 kafka]$ bin/kafka-server-stop.sh

4.3 Kafka 副本

4.3.1 副本基本信息

（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 副本同步时，延迟过多的副本。

4.3.2 Leader 选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群
broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。
Controller 的信息同步工作是依赖于 Zookeeper 的。

（1）创建一个新的 topic，4 个分区，4 个副本

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --topic chenyunde --partitions 4
–replication-factor 4

Created topic chenyunde. （2）查看 Leader 分布情况

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 3 Replicas: 3,0,2,1 Isr: 3,0,2,1
Topic: chenyunde Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,2,3,0
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,3,1,2
Topic: chenyunde Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 2,1,0,3

（3）停止掉 hadoop105 的 kafka 进程，并查看 Leader 分区情况

[chenyunde@hadoop105 kafka]$ bin/kafka-server-stop.sh
[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,2,1

Topic: chenyunde Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,2,0
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,2
Topic: chenyunde Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 2,1,0

（4）停止掉 hadoop104 的 kafka 进程，并查看 Leader 分区情况

[chenyunde@hadoop104 kafka]$ bin/kafka-server-stop.sh
[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1
Topic: chenyunde Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1
Topic: chenyunde Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0

（5）启动 hadoop105 的 kafka 进程，并查看 Leader 分区情况

[chenyunde@hadoop105 kafka]$ bin/kafka-server-start.sh -daemon
config/server.properties [chenyunde@hadoop102 kafka]$
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe
–topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1,3
Topic: chenyunde Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0,3
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,3
Topic: chenyunde Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0,3

（6）启动 hadoop104 的 kafka 进程，并查看 Leader 分区情况

[chenyunde@hadoop104 kafka]$ bin/kafka-server-start.sh -daemon
config/server.properties [chenyunde@hadoop102 kafka]$
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe
–topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1,3,2
Topic: chenyunde Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0,3,2
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,3,2
Topic: chenyunde Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0,3,2

（7）停止掉 hadoop103 的 kafka 进程，并查看 Leader 分区情况

[chenyunde@hadoop103 kafka]$ bin/kafka-server-stop.sh
[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic chenyunde

Topic: chenyunde TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: chenyunde Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,3,2
Topic: chenyunde Partition: 1 Leader: 2 Replicas: 1,2,3,0 Isr: 0,3,2
Topic: chenyunde Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,3,2
Topic: chenyunde Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 0,3,2

4.3.3 Leader 和 Follower 故障处理细节

1. follower故障处理细节

图解

1. Leader是先收到数据，Follower后拉取数据，消费者能够见到的最大的offset是HW-1
2. 如果Follower发生故障（broker2），第一件事会把它从ISR队列中踢出（ISR[0,1]），这个期间Leader和Follower会继续接收数据，HW和LEO都在增加
3. 待该Follower恢复后，Follower会读取本地磁盘记录的上次HW，并将log文件高于HW的部分截掉，从HW开始向Leader进行同步
4. 等待Follower的LEO大于等于该Partition的HW，即Follower追上Leader之后，就可以重新加入ISR

2. leader故障处理细节

关键词：
LEO：指的是每个副本最大的offset；
HW：指的是消费者能见到的最大的offset，ISR队列中最小的LEO。
（1）follower故障
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
（2）leader故障
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

4.3.4 分区副本分配

如果 kafka 服务器只有 4 个节点，那么设置 kafka 的分区数大于服务器台数，在 kafka
底层如何分配存储副本呢？
1）创建 16 分区，3 个副本
（1）创建一个新的 topic，名称为 second。

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --partitions 16 --replication-factor 3 –
topic second

（2）查看分区和副本情况。

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic second

Topic: second4 Partition: 0 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 2 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 3 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1
Topic: second4 Partition: 4 Leader: 0 Replicas: 0,2,3 Isr: 0,2,3
Topic: second4 Partition: 5 Leader: 1 Replicas: 1,3,0 Isr: 1,3,0
Topic: second4 Partition: 6 Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
Topic: second4 Partition: 7 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: second4 Partition: 8 Leader: 0 Replicas: 0,3,1 Isr: 0,3,1
Topic: second4 Partition: 9 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2
Topic: second4 Partition: 10 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: second4 Partition: 11 Leader: 3 Replicas: 3,2,0 Isr: 3,2,0
Topic: second4 Partition: 12 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 13 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 14 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 15 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1

4.3.5 生产经验——手动调整分区副本存储

手动调整分区副本存储的步骤如下：
（1）创建一个新的 topic，名称为 three。

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --partitions 4 --replication-factor 2 – topic
three

（2）查看分区副本存储情况。

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic three

（3）创建副本存储计划（所有副本都指定存储在 broker0、broker1 中）。

[chenyunde@hadoop102 kafka]$ vim increase-replication-factor.json

输入如下内容： {

"version":1,
"partitions":[{"topic":"three","partition":0,"replicas":[0,1]},
{"topic":"three","partition":1,"replicas":[0,1]},
{"topic":"three","partition":2,"replicas":[1,0]},
{"topic":"three","partition":3,"replicas":[1,0]}] } 

（4）执行副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --execute

（5）验证副本存储计划。

[chenyunde@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh –
bootstrap-server hadoop102:9092 --reassignment-json-file
increase-replication-factor.json --verify

（6）查看分区副本存储情况。

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic three

4.3.6 生产经验——Leader 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 负载是否平衡的间隔时间。

4.4 文件存储

4.4.1 文件存储机制

1. Topic数据的存储机制
   

2．查看文件存储
1）查看hadoop102的kafka文件存储

[chenyunde@hadoop104 first-1]$ ls

00000000000000000092.index
00000000000000000092.log
00000000000000000092.snapshot
00000000000000000092.timeindex
leader-epoch-checkpoint
partition.metadata

2）直接查看log日志，是乱码需要使用工具查看

[chenyunde@hadoop104 first-1]$ cat 00000000000000000092.log

\CYnF|©|©ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ"hello world

3）通过工具查看
查看index文件

[chenyunde@hadoop104 first-1]$ kafka-run-class.sh

kafka.tools.DumpLogSegments --files ./00000000000000000000.index 
Dumping ./00000000000000000000.index
offset: 3 position: 152

查看log文件

[chenyunde@hadoop104 first-1]$ kafka-run-class.sh

kafka.tools.DumpLogSegments --files ./00000000000000000000.log
Dumping datas/first-0/00000000000000000000.log
Starting offset: 0
baseOffset: 0 lastOffset: 1 count: 2 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 0 CreateTime: 1636338440962 size: 75 magic: 2 compresscodec: none crc: 2745337109 isvalid: true
baseOffset: 2 lastOffset: 2 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 75 CreateTime: 1636351749089 size: 77 magic: 2 compresscodec: none crc: 273943004 isvalid: true
baseOffset: 3 lastOffset: 3 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 152 CreateTime: 1636351749119 size: 77 magic: 2 compresscodec: none crc: 106207379 isvalid: true
baseOffset: 4 lastOffset: 8 count: 5 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 229 CreateTime: 1636353061435 size: 141 magic: 2 compresscodec: none crc: 157376877 isvalid: true
baseOffset: 9 lastOffset: 13 count: 5 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 370 CreateTime: 1636353204051 size: 146 magic: 2 compresscodec: none crc: 4058582827 isvalid: true

3. index文件和log文件详解
   1）详解
   

图解

• Segement-0[offset:0-521]对应的是 00000000000000000000.index和00000000000000000000.log;
• Segement-1[offset:522-1004]对应的是 00000000000000000522.index和00000000000000001004.log;
• Segement-1[offset:1005-]对应的是 00000000000000001005.index和00000000000000001005.log;
• 每一个Segement大小都是1G，kafka设计index为稀疏索引，大约每往log文件写入4kb数据，会往index文件写入一条索引。参数log.index.interval.bytes默认4kb
• 如何在log文件中定位找到一个offset为600的Record——600大于522小于1005，所以在00000000000000000522.index文件中寻找
• Index文件中保存的offset为相对offset，这样能确保offset的值所占空间不会过大，因此能将offset的值控制在固定大小

定位：

1. 根据目标offset定位到Segment文件
2. 找到小于等于目标offset到最大offset对应的索引项
3. 定位到log文件
4. 向下遍历找到目标Record

2）日志存储参数配置

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

4.4.2 文件清理策略

1. kafka数据文件保存时间：默认是7天
2. kafka数据文件保存可通过如下参数修改
   ① log.retention.hours：最低优先级小时， 默认7天（168小时）
   ② log.retention.minutes：分钟
   ③ log.retention.ms：最高优先级毫秒
   ④ log.retention.check.interval.ms：负责设置检查周期，默认5分钟。
   3．那么一旦超过了设置的时间就会采取清理策略，清理策略有两种：delete和compact
   1）delete策略
   delete日志删除：将过期数据删除。
   配置：log.cleanup.policy=delete
   基于时间：默认打开，以segment中所有记录中的最大时间戳作为文件时间戳
   基于大小：默认关闭，超过设置的所有日志大小，删除最早的segment。
   log.retention.bytes，默认等于-1，表示无穷大。

2）compact日志策略

4.5 高效读写数据(高频)

1．Kafka本身是分布式集群，可以采用分区技术，并行度高
2．读数据采用稀疏索引，可以快速定位要消费的数据
3．顺序写磁盘
Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

4. 页缓存+零拷贝技术
   
   参数| 描述
   |–|–|
   log.flush.interval.messages| 强制页缓存刷写到磁盘的条数，默认是long的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。
   log.flush.interval.ms| 每隔多久，刷数据到磁盘，默认是null。一般不建议修改，交给系统自己管理。

第5章 Kafka消费者

5.1 Kafka消费方式

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

push（推）	模式 很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。
pull模式	可以根据consumer的消费能力以适当的速率消费消息。不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。

5.2 Kakfa消费者工作流程

5.2.1 消费者总体工作流程

5.2.2 消费者组原理

图解

• 生产者把数据发送给集群，由多个消费者如何组成消费者组
• coordinator是辅助实现消费者组的初始化和分区的分配
• 每一个broker节点都有对应的一个coordinator，消费者组如何选择哪个coordinator来辅助它进行后续的工作呢
• coordinator节点选择取决于groupid的hashcode的值，groupid是用户写代码时手动给的值，它的hashcode值对50求模，50是因为未来存储消费者组的offset对应的分区数是50（事务协调器也是），可以对主题分区数进行修改50的值
• 例如：组id的hashcode值为1，求模后等于1，对应这它主题的1号分区，在哪个broker上，这个broker上的coordinator就作为这个消费者组的初始化和分区的分配的协调者（老大）
• 开始工作

1. 首先是所有的消费者都会主动的向老大发送JoinGroup加组请求
2. 老大会从全部消费者当中随机选出一个作为leader
3. 老大会把收到的所有消费者给它汇报的信息（要消费的topic情况）发送到leader，辅助消费者工作
4. leader要制定一个消费方案
5. 制定完方案发送给老大coordinator
6. 老大就把消费方案都发给所有小弟消费者，都按照这个规则进行消费避免冲突
7. 消费者都会定期的跟老大进行心跳通讯（默认3秒），如果在45s内（session.timeout.ms=45s）没有发送任何消息，老大认为这个消费者挂了，一旦消费者挂了，组类其他消费者就要帮助它把后续工作干了，这是消费者被移除且触发在平衡（把它的任务分配给其他消费者）或者消费者处理的时间过长（max.poll.interval.s=5min）,也会触发再平衡

图解

1. 消费者要开始工作首先要创建一个消费者网络连接（ConsumerNetworkClient），主要是用来跟kafka集群进行交互的
2. 前期准备工作，消费者组调用一个sendFetches方法，用来抓取数据初始化
3. 参数有：Fetch.min.bytes每批次抓取最小的字节数，默认是1字节，只要有一个字节在kafka集群就可以抓取过来；Fetch.max.wait.ms超时时间，一批数据最小值为到达的超时时间默认500ms，只要时间到达500毫秒就算没到1字节也可以拉取数据；Fetch.max.bytes最大每批次上线是50m
4. 准备完毕后调用send方法发送请求，发送请求后会通过回调方法onSuccess把对应的结果拉取过来，拉取过来的数据（completedFetches）会放到一个消息队列，一批一批的放入（有可能一批是1字节或者50m）
5. 消费者会一批次拉取（FetchedRecords从队列中抓取数据）500条（Max.poll.records一次拉取数据返回消息的最大条数默认500）进行正常的处理
6. 处理：反序列化（生产者进行了序列化），经过拦截器（kafka整个集群不用来处理数据只用来存数据，想要处理数据只有生产端和消费端拦截器，可以方便监控kafka集群的运行情况，可以记录进来出去多少数据）

5.2.3 消费者重要参数

参数名称	描述
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， 表示消费者提交偏移量频率，默认5s。
auto.offset.reset	当Kafka中没有初始偏移量或当前偏移量在服务器中不存在（如，数据被删除了），该如何处理？ earliest：自动重置偏移量到最早的偏移量。 latest：默认，自动重置偏移量为最新的偏移量。 none：如果消费组原来的（previous）偏移量不存在，则向消费者抛异常。 anything：向消费者抛异常。
offsets.topic.num.partitions	__consumer_offsets的分区数，默认是50个分区。
heartbeat.interval.ms	Kafka消费者和coordinator之间的心跳时间，默认3s。该条目的值必须小于 session.timeout.ms ，也不应该高于 session.timeout.ms 的1/3。
session.timeout.ms	Kafka消费者和coordinator之间连接超时时间，默认45s。超过该值，该消费者被移除，消费者组执行再平衡。
max.poll.interval.ms	消费者处理消息的最大时长，默认是5分钟。超过该值，该消费者被移除，消费者组执行再平衡。
fetch.min.bytes	默认1个字节。消费者获取服务器端一批消息最小的字节数。
fetch.max.wait.ms	默认500ms。如果没有从服务器端获取到一批数据的最小字节数。该时间到，仍然会返回数据。
fetch.max.bytes	默认Default: 52428800（50 m）。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值（50m）仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受message.max.bytes （broker config）or max.message.bytes （topic config）影响。
max.poll.records	一次poll拉取数据返回消息的最大条数，默认是500条。

5.3 消费者API

5.3.1 独立消费者案例（订阅主题）

1. 需求：创建一个独立消费者，消费first主题中的数据
   注意：在消费者API代码中必须配置消费者组id。
2. 案例实操：
   1）创建包名：com.chenyunde.kafka.consumer
   2）编写代码：

package com.chenyunde.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 java.time.Duration;
import java.util.ArrayList;
import java.util.Properties;
public class CustomConsumer {
    public static void main(String[] args) {
        // 1.创建消费者的配置对象
        Properties properties = new Properties();
        // 2.给消费者配置对象添加参数
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化 必须
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        // 配置消费者组 必须
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test");
        // 3. 创建消费者对象
        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(properties);
        // 4. 订阅主题
        ArrayList<String> topics= new ArrayList<>();
        topics.add("first");
        consumer.subscribe(topics);
        // 5. 拉取数据打印
        while (true) {
            ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofSeconds(1));
            // 6. 遍历并输出消费到的数据
            for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
                System.out.println(consumerRecord);
            }
        }
    }
}

3）测试
① 在IDEA中执行消费者程序
② hadoop102中创建kafka生产者，并输入数据

[chenyunde@hadoop102 kafka]$ bin/kafka-console-producer.sh
–bootstrap-server hadoop102:9092 --topic first

hello

③ 在IDEA中观察接收到的数据

ConsumerRecord(topic = first, partition = 1, leaderEpoch = 3, offset = 0, CreateTime = 1629160841112, serialized key size = -1, serialized value size = 5, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = hello)

5.3.2 消费者组案例
1）需求：观察消费者组消费数据时的如下特点
①消费者组中的消费者消费不同分区的数据
②消费者数量大于Topic的分区数时，会有消费者消费不到数据
③每当消费者组内成员数发生变化时，就会进行主题分区对消费者的重分配
2）案例实操
① 添加日志框架jar
配置日志框架，可以将kafka的运行日志打印在控制台。

<dependency>
    <groupId>org.apache.logging.log4jgroupId>
    <artifactId>log4j-slf4j-implartifactId>
    <version>2.12.0version>
dependency>

② 创建主题
创建一个只有两个分区的Topic，Topic的名字为”groupTest01”

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --replication-factor 2 --partitions 2 --topic
groupTest01

④编辑消费者
复制两份基础消费者的代码，消费者组改为”group01”,订阅主题修改为”groupTest01”，在idea中同时启动，即可启动同一个消费者组中的两个消费者。

package com.chenyunde.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 java.time.Duration;
import java.util.ArrayList;
import java.util.Properties;
public class CustomConsumer {
    public static void main(String[] args) {
        // 1.创建消费者的配置对象
        Properties properties = new Properties();
        // 2.给消费者配置对象添加参数
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化 必须
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        // 配置消费者组 必须
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "group01");
        // 3. 创建消费者对象
        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(properties);
        // 4. 订阅主题
        ArrayList<String> topics= new ArrayList<>();
        topics.add("groupTest01");
        consumer.subscribe(topics);
        // 5. 拉取数据打印
        while (true) {
            ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofSeconds(1));
            // 6. 遍历并输出消费到的数据
            for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
                System.out.println(consumerRecord);
            }
        }
    }
}
⑤启动生产者后，观察控制台输出，先启动一个消费者CustomConsumer01后，观察控制台输出
Successfully synced group in generation Generation{generationId=1, memberId='consumer-group01-1-44ba7ef2-e39b-4d3d-a78f-0c1afeceb871', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1])
Adding newly assigned partitions: groupTest01-1, groupTest01-0
⑤ 再启动一个消费者CustomConsumer02后，观察控制台输出
// CustomConsumer01控制台输出
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group01-1-44ba7ef2-e39b-4d3d-a78f-0c1afeceb871', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0])
Adding newly assigned partitions: groupTest01-0

// CustomConsumer02控制台输出
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group01-1-acc35e3e-371b-4702-8b9b-376c6144e676', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-1])
Adding newly assigned partitions: groupTest01-1

上述现象可知：消费者组成员增加时，会触发分区重分配，每个消费者消费不同分区的数据
思考：如果再新增一个消费者会发生什么？

5.4 生产经验——分区分配策略及再平衡

参数名称	描述
heartbeat.interval.ms	Kafka消费者和coordinator之间的心跳时间，默认3s。该条目的值必须小于 session.timeout.ms，也不应该高于 session.timeout.ms 的1/3。
session.timeout.ms	Kafka消费者和coordinator之间连接超时时间，默认45s。超过该值，该消费者被移除，消费者组执行再平衡。
max.poll.interval.ms	消费者处理消息的最大时长，默认是5分钟。超过该值，该消费者被移除，消费者组执行再平衡。
partition.assignment.strategy	消费者分区分配策略，默认策略是Range + CooperativeSticky。Kafka可以同时使用多个分区分配策略。可以选择的策略包括：Range、RoundRobin、Sticky、CooperativeSticky

5.4.1 生产者分区分配之Range及再平衡

1. Range分区策略原理
   

2. Range分区分配策略及再平衡案例
   1）准备
   ① 修改主题groupTest01的分区为7个分区

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --alter --topic groupTest01–partitions 7

② 创建3个消费者，并组成消费者组group02，消费主题groupTest01
③ 观察分区分配情况
启动第一个消费者，观察分区分配情况

// consumer01
Successfully synced group in generation Generation{generationId=1, memberId='consumer-group02-1-4b019db6-948a-40d2-9d8d-8bbd79f59b14', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2, groupTest01-3, groupTest01-4, groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-3, groupTest01-2, groupTest01-1, groupTest01-0, groupTest01-6, groupTest01-5, groupTest01-4

启动第二个消费者，观察分区分配情况

// consumer01
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group02-1-4b019db6-948a-40d2-9d8d-8bbd79f59b14', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2, groupTest01-3])
Adding newly assigned partitions: groupTest01-3, groupTest01-2, groupTest01-1, groupTest01-0
// consumer02
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group02-1-60afd984-6916-4101-8e72-ae52fa8ded6c', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-4, groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-6, groupTest01-5, groupTest01-4

启动第三个消费者，观察分区分配情况

// consumer01
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group02-1-4b019db6-948a-40d2-9d8d-8bbd79f59b14', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2])
Adding newly assigned partitions: groupTest01-2, groupTest01-1, groupTest01-0
// consumer02
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group02-1-60afd984-6916-4101-8e72-ae52fa8ded6c', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-3, groupTest01-4])
Adding newly assigned partitions: groupTest01-3, groupTest01-4
// consumer03
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group02-1-fd15f50f-0a33-4e3a-8b8c-237252a41f4d', protocol='range'}
Notifying assignor about the new Assignment(partitions=[groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-6, groupTest01-5

思考：如果有消费者退出，分区分配会是什么样子？

5.4.2 生产者分区分配之RoundRobin策略及再平衡

1. RoundRobin分区分配策略原理
   

2. RoundRobin分区分配策略及再平衡案例
   案例实操
   修改消费者代码，消费者组都是group03。
   修改分区分配策略为roundrobin

properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, RoundRobinAssignor.class.getName());

依次启动3个消费者，观察控制台输出
启动消费者CustomConsumer01，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=1, memberId='consumer-group03-1-2d38c78b-b17d-4d43-93f5-4b676f703177', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2, groupTest01-3, groupTest01-4, groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-3, groupTest01-2, groupTest01-1, groupTest01-0, groupTest01-6, groupTest01-5, groupTest01-4

启动消费者CustomConsumer02，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group03-1-2d38c78b-b17d-4d43-93f5-4b676f703177', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-2, groupTest01-4, groupTest01-6])
Adding newly assigned partitions: groupTest01-2, groupTest01-0, groupTest01-6, groupTest01-4
// customConsumter02
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group03-1-5771a594-4e99-47e8-9df6-ca820af6698b', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-1, groupTest01-3, groupTest01-5])
Adding newly assigned partitions: groupTest01-3, groupTest01-1, groupTest01-5

启动消费者CustomConsumer03，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group03-1-2d38c78b-b17d-4d43-93f5-4b676f703177', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-3, groupTest01-6])
Adding newly assigned partitions: groupTest01-3, groupTest01-0, groupTest01-6
// customConsumter02
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group03-1-5771a594-4e99-47e8-9df6-ca820af6698b', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-1, groupTest01-4])
Adding newly assigned partitions: groupTest01-1, groupTest01-4
// customConsumter03
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group03-1-d493b011-d6ea-4c36-8ae5-3597db635219', protocol='roundrobin'}
Notifying assignor about the new Assignment(partitions=[groupTest01-2, groupTest01-5])
Adding newly assigned partitions: groupTest01-2, groupTest01-5

思考：如果有消费者退出，分区分配会是什么样子？

5.4.3 生产者分区分配之Sticky及再平衡

1. 粘性分区定义：
   可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。粘性分区是Kafka从0.11.x版本开始引入这种分配策略，首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。
2. Sticky分区分配策略及再平衡案例

1. 修改分区分配策略，修改消费者组为groupTest03
   // 修改分区分配策略

properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,
StickyAssignor.class.getName());

2. 分别启动三个消费者后，查看第三次分配如下
   启动消费者CustomConsumer01，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=1, memberId='consumer-group06-1-19e1e6a4-e2ca-467d-909f-3769dc527d34', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2, groupTest01-3, groupTest01-4, groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-3, groupTest01-2, groupTest01-1, groupTest01-0, groupTest01-6, groupTest01-5, groupTest01-4

启动消费者CustomConsumer02，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group06-1-19e1e6a4-e2ca-467d-909f-3769dc527d34', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2, groupTest01-3])
Adding newly assigned partitions: groupTest01-3, groupTest01-2, groupTest01-1, groupTest01-0
// customConsumer02
Successfully synced group in generation Generation{generationId=2, memberId='consumer-group06-1-6ea3622c-bbe8-4e13-8803-d5431a224671', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-4, groupTest01-5, groupTest01-6])
Adding newly assigned partitions: groupTest01-6, groupTest01-5, groupTest01-4

启动消费者CustomConsumer03，观察控制台输出

// customConsumer01
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group06-1-19e1e6a4-e2ca-467d-909f-3769dc527d34', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-0, groupTest01-1, groupTest01-2])
Adding newly assigned partitions: groupTest01-2, groupTest01-1, groupTest01-0
// customConsumer02
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group06-1-6ea3622c-bbe8-4e13-8803-d5431a224671', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-4, groupTest01-5])
Adding newly assigned partitions: groupTest01-5, groupTest01-4
// customConsumer03
Successfully synced group in generation Generation{generationId=3, memberId='consumer-group06-1-eb0ac20c-5d94-43a7-b7c1-96a561513995', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-3, groupTest01-6])
Adding newly assigned partitions: groupTest01-3, groupTest01-6

3. 杀死消费者CustomConsumer01后，观察控制台输出

// customConsumer02
Successfully synced group in generation Generation{generationId=4, memberId='consumer-group06-1-6ea3622c-bbe8-4e13-8803-d5431a224671', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-4, groupTest01-5, groupTest01-0, groupTest01-2])
Adding newly assigned partitions: groupTest01-2, groupTest01-0, groupTest01-5, groupTest01-4
// customConsumer03
Successfully synced group in generation Generation{generationId=4, memberId='consumer-group06-1-eb0ac20c-5d94-43a7-b7c1-96a561513995', protocol='sticky'}
Notifying assignor about the new Assignment(partitions=[groupTest01-3, groupTest01-6, groupTest01-1])
Adding newly assigned partitions: groupTest01-3, groupTest01-1, groupTest01-6

5.5 offset位移

5.5.1 offset的默认维护位置

由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中，从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。
在__consumer_offsets主题里面采用key+value的方式存储数据。key是groupId+topic+分区号,value是当前offset的值。每个一段时间，kafka内部就会对这个topic进行compact，即每个groupId+topic+分区号就保留最新的数据。
1.消费offset案例
1）设计思想:
__consumer_offsets 为kafka中的topic， 那就可以通过消费者进行消费.
2）在配置文件config/consumer.properties中添加配置exclude.internal.topics=false,默认就是true，表示不能消费系统主题。我们为了查看系统主题数据，需要将参数修改为false。

[chenyunde@hadoop102 kafka]$ vim
/opt/module/kafka/config/consumer.properties
exclude.internal.topics=false

3）在命令行创建一个新的topic

[chenyunde@hadoop102 kafka]$ bin/kafka-topics.sh --create --topic
chenyunde --bootstrap-server hadoop102:9092 --partitions 2
–replication-factor 2

4）启动生产者向主题chenyunde中生产数据

[chenyunde@hadoop102 kafka]$ bin/kafka-console-producer.sh --topic
chenyunde --bootstrap-server hadoop102:9092

5）启动消费者消费主题chenyunde中的数据

[chenyunde@hadoop104 kafka]$ bin/kafka-console-consumer.sh
–bootstrap-server hadoop102:9092 --topic chenyunde --group test

注意：指定消费者组的名称，能够更好的观察数据存储位置（key—>groupId+toipc+分区号）。
6）启动消费者消费主题__consumer_offsets

[chenyunde@hadoop102 kafka]$ bin/kafka-console-consumer.sh --topic
__consumer_offsets --bootstrap-server hadoop102:9092 --consumer.config config/consumer.properties --formatter

"kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter" --from-beginning

7）消费到的数据

[test,chenyunde,1]::OffsetAndMetadata(offset=7, leaderEpoch=Optional[0], metadata=, commitTimestamp=1622442520203, expireTimestamp=None)
[test,chenyunde,0]::OffsetAndMetadata(offset=8, leaderEpoch=Optional[0], metadata=, commitTimestamp=1622442520203, expireTimestamp=None)

5.5.2 自动提交offset

1. 自动提交offset图示
   
   2.编写代码
   1）需要用到的类：
   KafkaConsumer：需要创建一个消费者对象，用来消费数据
   ConsumerConfig：获取所需的一系列配置参数
   ConsuemrRecord：每条数据都要封装成一个ConsumerRecord对象
   为了使我们能够专注于自己的业务逻辑，Kafka提供了自动提交offset的功能。
   2）自动提交offset的相关参数：
   enable.auto.commit：是否开启自动提交offset功能,默认true，
   auto.commit.interval.ms：自动提交offset的时间间隔，默认5s。
   3）消费者自动提交offset

package com.chenyunde.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 java.util.Arrays;
import java.util.Properties;
 
public class CustomConsumer {
    public static void main(String[] args) {
        // 1. 创建kafka消费者配置类
        Properties properties = new Properties();
        // 2. 添加配置参数
        // 添加连接
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化 必须
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        // 配置消费者组
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test");
        // 是否自动提交offset
        properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
        // 提交offset的时间周期，默认5s，
        properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

        // 3. 创建kafka消费者
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);

        // 4. 设置消费主题  形参是列表
        consumer.subscribe(Arrays.asList("first"));

        // 5. 消费数据
        while (true){
            // 6. 读取消息
            ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofSeconds(1));

            // 7. 输出消息
            for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
                System.out.println(consumerRecord.value());
            }
        }
    }
}

5.5.3 手动提交offset

1. 手动提交offset图示：
   
   1）同步提交offset
   由于同步提交offset有失败重试机制，故更加可靠，以下为同步提交offset的示例。

package com.chenyunde.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 java.util.Arrays;
import java.util.Properties;

public class CustomConsumerByHand {
    public static void main(String[] args) {
        // 1. 创建kafka消费者配置类
        Properties properties = new Properties();
        // 2. 添加配置参数
        // 添加连接
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化 必须
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        // 配置消费者组
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test");
        // 是否自动提交offset
        properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
        // 提交offset的时间周期
        properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

        // 3. 创建kafka消费者
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);

        // 4. 设置消费主题  形参是列表
        consumer.subscribe(Arrays.asList("first"));

        // 5. 消费数据
        while (true){
            // 6. 读取消息
            ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofSeconds(1));

            // 7. 输出消息
            for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
                System.out.println(consumerRecord.value());
            }
// 同步提交offset
            consumer.commitSync();
        }

    }
}

2）异步提交offset
虽然同步提交offset更可靠一些，但是由于其会阻塞当前线程，直到提交成功。因此吞吐量会受到很大的影响。因此更多的情况下，会选用异步提交offset的方式。
以下为异步提交offset的示例：

package com.chenyunde.kafka.consumer;

import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;
import java.util.Arrays;
import java.util.Map;
import java.util.Properties;

public class CustomConsumerByHand {
    public static void main(String[] args) {
         // 1. 创建kafka消费者配置类
        Properties properties = new Properties();
        // 2. 添加配置参数
        // 添加连接
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化 必须
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        // 配置消费者组
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test");
        // 是否自动提交offset
        properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
        // 提交offset的时间周期
        properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

        // 3. 创建kafka消费者
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);

        // 4. 设置消费主题  形参是列表
        consumer.subscribe(Arrays.asList("first"));

        // 5. 消费数据
        while (true){
            // 6. 读取消息
            ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofSeconds(1));

            // 7. 输出消息
            for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
                System.out.println(consumerRecord.value());
            }

            // 异步提交offset
            consumer.commitAsync(new OffsetCommitCallback() {
                /**
                 * 回调函数输出
                 * @param offsets   offset信息
                 * @param exception 异常
                 */
                @Override
                public void onComplete(Map<TopicPartition, OffsetAndMetadata> offsets, Exception exception) {
                    // 如果出现异常打印
                    if (exception != null ){
                        System.err.println("Commit failed for " + offsets);
                    }
                }
            });
        }

    }
}

5.5.4 指定Offset消费

auto.offset.reset = earliest | latest | none |
当Kafka中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办?
（1）earliest：自动将偏移量重置为最早的偏移量
（2）latest(默认值)：自动将偏移量重置为最新偏移量
（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常

5.5.5 数据漏消费和重复消费分析

1. 问题：无论是同步提交还是异步提交offset，都有可能会造成数据的漏消费或者重复消费。
2. 漏消费：先提交offset后消费，有可能造成数据的漏消费；
3. 重复消费：而先消费后提交offset，有可能会造成数据的重复消费。
   
   思考：怎么才能做到既不漏消费也不重复消费呢？

5.6 生产经验之Consumer事务

1. 消费者事务
   

5.7 生产经验——数据积压（消费者如何提高吞吐量）

参数名称	描述
fetch.max.bytes	默认Default: 52428800（50 m）。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值（50m）仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受message.max.bytes （broker config）or max.message.bytes （topic config）影响。
max.poll.records	一次poll拉取数据返回消息的最大条数，默认是500条

第6章 Kafka-Eagle监控

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

6.1 kafka准备

1. 关闭kafka集群

[chenyunde@hadoop102 kafka]$ kafka.sh stop

2.修改kafka启动命令

[chenyunde@hadoop102 kafka]$ vim
/opt/module/kafka/bin/kafka-server-start.sh

……

if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
    export KAFKA_HEAP_OPTS="-server -Xms2G -Xmx2G -XX:PermSize=128m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70"
    export JMX_PORT="9999"
    #export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
fi

注意：修改之后在启动Kafka之前要分发之其他节点

6.2 安装kafka-Eagle

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

[chenyunde@hadoop102 software]$ ll
-rw-rw-r–. 1 chenyunde chenyunde 81074069 4月 19 20:07 kafka-eagle-bin-2.0.8.tar.gz

2. 将jar包解压到本地

[chenyunde@hadoop102 software]$ tar -zxvf kafka-eagle-bin-2.0.8.tar.gz

3. 进入刚才解压的目录，再次将jar包解压到/opt/module/目录下

[chenyunde@hadoop102 kafka-eagle-bin-2.0.8]$ tar -zxvf
efak-web-2.0.8-bin.tar.gz -C /opt/module/

4. 修改kafka-eagle名称为eagle

[chenyunde@hadoop102 module]$ mv efak-web-2.0.8/ efak

6.3 配置eagle

1. 修改eagle的配置文件system-config.properties

[chenyunde@hadoop102 efak]$ vim conf/system-config.properties

######################################
multi zookeeper & kafka cluster list
Settings prefixed with 'kafka.eagle.' will be deprecated, use 'efak.' instead
######################################
efak.zk.cluster.alias=cluster1
cluster1.zk.list=hadoop102:2181,hadoop103:2181,hadoop104:2181/kafka

######################################
# zookeeper enable acl
######################################
cluster1.zk.acl.enable=false
cluster1.zk.acl.schema=digest
cluster1.zk.acl.username=test
cluster1.zk.acl.password=test123

######################################
# broker size online list
######################################
cluster1.efak.broker.size=20

######################################
# zk client thread limit
######################################
kafka.zk.limit.size=32

######################################
# EFAK webui port
######################################
efak.webui.port=8048

######################################
# kafka jmx acl and ssl authenticate
######################################
cluster1.efak.jmx.acl=false
cluster1.efak.jmx.user=keadmin
cluster1.efak.jmx.password=keadmin123
cluster1.efak.jmx.ssl=false
cluster1.efak.jmx.truststore.location=/data/ssl/certificates/kafka.truststore
cluster1.efak.jmx.truststore.password=ke123456

######################################
# kafka offset storage
######################################
cluster1.efak.offset.storage=kafka

######################################
# kafka jmx uri
######################################
cluster1.efak.jmx.uri=service:jmx:rmi:///jndi/rmi://%s/jmxrmi

######################################
# kafka metrics, 15 days by default
######################################
efak.metrics.charts=true
efak.metrics.retain=15

######################################
# kafka sql topic records max
######################################
efak.sql.topic.records.max=5000
efak.sql.topic.preview.records.max=10

######################################
# delete kafka topic token
######################################
efak.topic.token=keadmin

######################################
# kafka sasl authenticate
######################################
cluster1.efak.sasl.enable=false
cluster1.efak.sasl.protocol=SASL_PLAINTEXT
cluster1.efak.sasl.mechanism=SCRAM-SHA-256
cluster1.efak.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="kafka" password="kafka-eagle";
cluster1.efak.sasl.client.id=
cluster1.efak.blacklist.topics=
cluster1.efak.sasl.cgroup.enable=false
cluster1.efak.sasl.cgroup.topics=
cluster2.efak.sasl.enable=false
cluster2.efak.sasl.protocol=SASL_PLAINTEXT
cluster2.efak.sasl.mechanism=PLAIN
cluster2.efak.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="kafka" password="kafka-eagle";
cluster2.efak.sasl.client.id=
cluster2.efak.blacklist.topics=
cluster2.efak.sasl.cgroup.enable=false
cluster2.efak.sasl.cgroup.topics=

######################################
# kafka ssl authenticate
######################################
cluster3.efak.ssl.enable=false
cluster3.efak.ssl.protocol=SSL
cluster3.efak.ssl.truststore.location=
cluster3.efak.ssl.truststore.password=
cluster3.efak.ssl.keystore.location=
cluster3.efak.ssl.keystore.password=
cluster3.efak.ssl.key.password=
cluster3.efak.ssl.endpoint.identification.algorithm=https
cluster3.efak.blacklist.topics=
cluster3.efak.ssl.cgroup.enable=false
cluster3.efak.ssl.cgroup.topics=

######################################
# kafka sqlite jdbc driver address
######################################
# 配置mysql连接
efak.driver=com.mysql.jdbc.Driver
efak.url=jdbc:mysql://hadoop102:3306/ke?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
efak.username=root
efak.password=你的密码


######################################
# kafka mysql jdbc driver address
######################################
#efak.driver=com.mysql.cj.jdbc.Driver
#efak.url=jdbc:mysql://127.0.0.1:3306/ke?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
#efak.username=root
#efak.password=你的密码

6.4 添加环境变量 
[chenyunde@hadoop102 kafka]$ sudo vim /etc/profile.d/my_env.sh

# kafkaEfak
export KE_HOME=/opt/module/efak
export PATH=$PATH:$KE_HOME/bin
注意：source /etc/profile
[chenyunde@hadoop102 kafka]$ source /etc/profile
6.5启动eagle
[chenyunde@hadoop102 efak]$ bin/ke.sh start
*******************************************************************
* Kafka Eagle Service has started success.
* Welcome, Now you can visit 'http://192.168.202.102:8048/ke'
* Account:admin ,Password:123456
*******************************************************************
* <Usage> ke.sh [start|status|stop|restart|stats] </Usage>
* <Usage> https://www.kafka-eagle.org/ </Usage>
*******************************************************************

注意：启动之前需要先启动ZK以及KAFKA

第7章 Kafka-Kraft模式

7.1 Kafka-Kraft架构

左图为Kafka现有架构，元数据在zookeeper中，运行时动态选举controller，由controller进行Kafka集群管理。右图为kraft模式架构（实验性），不再依赖zookeeper集群，而是用三台controller节点代替zookeeper，元数据保存在controller中，由controller直接进行Kafka集群管理。
这样做的好处有以下几个：
1)Kafka不再依赖外部框架，而是能够独立运行；
2)controller管理集群时，不再需要从zookeeper中先读取数据，集群性能上升；
3)由于不依赖zookeeper，集群扩展时不再受到zookeeper读写能力限制；
4)controller不再动态选举，而是由配置文件规定。这样我们可以有针对性的加强controller节点的配置，而不是像以前一样对随机controller节点的高负载束手无策。

7.2 Kafka-Kraft集群部署

1）再次解压一份kafka安装包

[chenyunde@hadoop102 software]$ tar -zxvf kafka_2.12-3.0.0.tgz -C
/opt/module/

2）重命名为kafka2

[chenyunde@hadoop102 module]$ mv kafka_2.12-3.0.0/ kafka2

3）在hadoop102上修改/opt/module/kafka2/config/kraft/server.properties配置文件

[chenyunde@hadoop102 kraft]$ vim server.properties

#kafka的角色（controller相当于主机、broker节点相当于从机，主机类似zk功能）
process.roles=broker, controller
#节点ID
node.id=2
#controller服务协议别名
controller.listener.names=CONTROLLER
#全Controller列表
controller.quorum.voters=2@hadoop102:9093,3@hadoop103:9093,4@hadoop104:9093
#不同服务器绑定的端口
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
#broker服务协议别名
inter.broker.listener.name=PLAINTEXT
#broker对外暴露的地址
advertised.Listeners=PLAINTEXT://hadoop102:9092
#协议别名到安全协议的映射
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
#kafka数据存储目录
log.dirs=/opt/module/kafka2/data

4）分发kafka2

[chenyunde@hadoop102 module]$ xsync kafka2/

注意：
① 在hadoop103和hadoop104上需要对node.id相应改变，值需要和controller.quorum.voters对应。
② 在hadoop103和hadoop104上需要根据各自的主机名称，修改相应的advertised.Listeners地址。

5）初始化集群数据目录
（1）首先生成存储目录唯一ID。

[chenyunde@hadoop102 kafka2]$ bin/kafka-storage.sh random-uuid
J7s9e8PPTKOO47PxzI39VA

（2）用该ID格式化kafka存储目录（三台节点）。

[chenyunde@hadoop102 kafka2]$ bin/kafka-storage.sh format -t
J7s9e8PPTKOO47PxzI39VA -c
/opt/module/kafka2/config/kraft/server.properties
[chenyunde@hadoop103 kafka2]$ bin/kafka-storage.sh format -t
J7s9e8PPTKOO47PxzI39VA -c
/opt/module/kafka2/config/kraft/server.properties
[chenyunde@hadoop104 kafka2]$ bin/kafka-storage.sh format -t
J7s9e8PPTKOO47PxzI39VA -c
/opt/module/kafka2/config/kraft/server.properties

6）启动kafka集群

[chenyunde@hadoop102 kafka2]$ bin/kafka-server-start.sh -daemon
config/kraft/server.properties [chenyunde@hadoop103 kafka2]$
bin/kafka-server-start.sh -daemon
config/kraft/server.properties [chenyunde@hadoop104 kafka2]$
bin/kafka-server-start.sh -daemon config/kraft/server.properties

7）停止kafka集群

[chenyunde@hadoop102 kafka2]$
bin/kafka-server-stop.sh [chenyunde@hadoop103 kafka2]$
bin/kafka-server-stop.sh [chenyunde@hadoop104 kafka2]$
bin/kafka-server-stop.sh

7.3 Kafka-Kraft集群启动停止脚本
1）在/home/chenyunde/bin目录下创建文件kf2.sh脚本文件

[chenyunde@hadoop102 bin]$ vim kf2.sh

脚本如下：

#! /bin/bash case $1 in "start"){
    for i in hadoop102 hadoop103 hadoop104
    do
        echo " --------启动 $i Kafka2-------"
        ssh $i "/opt/module/kafka2/bin/kafka-server-start.sh -daemon /opt/module/kafka2/config/kraft/server.properties"
    done };; "stop"){
    for i in hadoop102 hadoop103 hadoop104
    do
        echo " --------停止 $i Kafka2-------"
        ssh $i "/opt/module/kafka2/bin/kafka-server-stop.sh "
    done };; esac

2）添加执行权限

[chenyunde@hadoop102 bin]$ chmod +x kf2.sh

3）启动集群命令

[chenyunde@hadoop102 ~]$ kf2.sh start

4）停止集群命令

[chenyunde@hadoop102 ~]$ kf2.sh stop