kafka安装及整合springboot

最新推荐文章于 2023-09-24 17:48:45 发布
最新推荐文章于 2023-09-24 17:48:45 发布
阅读量286 收藏
点赞数
分类专栏： 软件安装 文章标签： kafka spring boot java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jdbcmeng/article/details/125433484
版权

kafka

**Kafka是一个分布式消息队列。**Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker

Kafka架构

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

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

3）Topic ：可以理解为一个队列；

4） Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic；

5）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic；

6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序；

7）Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka。

Kafka搭建

1）解压安装包

[atguigu@hadoop102 software]$ tar -zxvf kafka_2.11-0.11.0.0.tgz -C /opt/module/

2）修改解压后的文件名称

[atguigu@hadoop102 module]$ mv kafka_2.11-0.11.0.0/ kafka

3）在/opt/module/kafka目录下创建logs文件夹

[atguigu@hadoop102 kafka]$ mkdir logs

4）修改配置文件

[atguigu@hadoop102 kafka]$ cd config/

[atguigu@hadoop102 config]$ vi server.properties

输入以下内容：

#broker的全局唯一编号，不能重复
broker.id=0
#删除topic功能使能
delete.topic.enable=true          --- 添加这一行
#处理网络请求的线程数量
num.network.threads=3
#用来处理磁盘IO的现成数量
num.io.threads=8
#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400
#接收套接字的缓冲区大小
socket.receive.buffer.bytes=102400
#请求套接字的缓冲区大小
socket.request.max.bytes=104857600
#kafka运行日志存放的路径	
log.dirs=/opt/module/kafka/logs    -- 这里要设置一下
#topic在当前broker上的分区个数
num.partitions=1
#用来恢复和清理data下数据的线程数量

num.recovery.threads.per.data.dir=1
#segment文件保留的最长时间，超时将被删除
log.retention.hours=168
#配置连接Zookeeper集群地址
zookeeper.connect=192.168.183.133:2181   --,hadoop103:2181,hadoop104:2181 如果是集群用，隔开

5）配置环境变量

[atguigu@hadoop102 module]$  vi /etc/profile
#KAFKA_HOME
export KAFKA_HOME=/opt/module/kafka
export PATH=$PATH:$KAFKA_HOME/bin
[atguigu@hadoop102 module]$ source /etc/profile

8）启动

#启动方法一：后台启动  末尾加&
[atguigu@hadoop102 kafka]$ bin/kafka-server-start.sh config/server.properties &
#启动方法二：控制台显示日志  不加&
[atguigu@hadoop103 kafka]$ bin/kafka-server-start.sh config/server.properties 

#关闭
./kafka-server-stop.sh stop

#查看是否启动
jps -l

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sbniNtet-1655983762849)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585904012631.png)]

kafka常用命令

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

    [root@promote bin]# ./kafka-topics.sh --zookeeper 127.0.0.1:2181 --list

  2. 创建topic

    [root@promote bin]# ./kafka-topics.sh --zookeeper 127.0.0.1:2181 --create --replication-factor 1 --partitions 1 --topic meng-demo01

    选项说明：

    –topic 定义topic名

    –replication-factor 定义副本数

    –partitions 定义分区数

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M23yl2c2-1655983762852)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585904228847.png)]

  3. 删除topic

    [root@promote bin]# ./kafka-topics.sh --zookeeper localhost:2181 --delete --topic meng-demo01

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4cnWTFWC-1655983762853)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585904364901.png)]

  4. 发布消息

    ./kafka-console-producer.sh --broker-list 127.0.0.1:9092 --topic first

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yPycNm8v-1655983762854)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585904760885.png)]

  5. 消费数据

./kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first --from-beginning   #这是kafka0.9版本后的新方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CZsVFoIb-1655983762855)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585905105227.png)]

–from-beginning：会把first主题中以往所有的数据都读取出来。根据业务场景选择是否增加该配置。

  1. 查看某个topic的详情

    ./kafka-topics.sh --zookeeper localhost:2181 --describe --topic first

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YwqW0ks0-1655983762855)(F:\教学资料\Java进阶\笔记–自己总结\assets\1585907263517.png)]

Kafka生产过程分析

写入方式

producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。

分区（Partition）

消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WjbvZc4q-1655983762856)(file:///C:\Users\MENGFA~1\AppData\Local\Temp\ksohtml16376\wps1.jpg)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RcLk00Cx-1655983762856)(file:///C:\Users\MENGFA~1\AppData\Local\Temp\ksohtml16376\wps2.jpg)]

我们可以看到，每个Partition中的消息都是有序的，生产的消息被不断追加到Partition log上，其中的每一个消息都被赋予了一个唯一的offset值。

1）分区的原因

（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；

（2）可以提高并发，因为可以以Partition为单位读写了。

2）分区的原则

（1）指定了patition，则直接使用；

（2）未指定patition但指定key，通过对key的value进行hash出一个patition；

（3）patition和key都未指定，使用轮询选出一个patition。

DefaultPartitioner类

public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
​        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
​        int numPartitions = partitions.size();
​        if (keyBytes == null) {
​            int nextValue = nextValue(topic);
​            List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
​            if (availablePartitions.size() > 0) {
​                int part = Utils.toPositive(nextValue) % availablePartitions.size();
​                return availablePartitions.get(part).partition();
​            } else {
​                // no partitions are available, give a non-available partition
​                return Utils.toPositive(nextValue) % numPartitions;
​            }
​        } else {
​            // hash the keyBytes to choose a partition
​            return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
​        }
​    }
副本Replication

同一个partition可能会有多个replication（对应 server.properties 配置中的 default.replication.factor=N）。没有replication的情况下，一旦broker 宕机，其上所有 patition 的数据都不可被消费，同时producer也不能再将数据存于其上的patition。引入replication之后，同一个partition可能会有多个replication，而这时需要在这些replication之间选出一个leader，producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据。

写入流程

producer写入消息流程如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jk5djJgo-1655983762857)(file:///C:\Users\MENGFA~1\AppData\Local\Temp\ksohtml16376\wps3.png)]

1）producer先从zookeeper的 "/brokers/…/state"节点找到该partition的leader

2）producer将消息发送给该leader

3）leader将消息写入本地log

4）followers从leader pull消息，写入本地log后向leader发送ACK

5）leader收到所有ISR中的replication的ACK后，增加HW（high watermark，最后commit 的offset）并向producer发送ACK

Broker 保存消息

3.2.1 存储方式

物理上把topic分成一个或多个patition（对应 server.properties 中的num.partitions=3配置），每个patition物理上对应一个文件夹（该文件夹存储该patition的所有消息和索引文件），如下：

[atguigu@hadoop102 logs]$ ll
drwxrwxr-x. 2 atguigu atguigu  4096 8月   6 14:37 first-0
drwxrwxr-x. 2 atguigu atguigu  4096 8月   6 14:35 first-1
drwxrwxr-x. 2 atguigu atguigu  4096 8月   6 14:37 first-2
[atguigu@hadoop102 logs]$ cd first-0
[atguigu@hadoop102 first-0]$ ll
-rw-rw-r--. 1 atguigu atguigu 10485760 8月   6 14:33 00000000000000000000.index
-rw-rw-r--. 1 atguigu atguigu      219 8月   6 15:07 00000000000000000000.log
-rw-rw-r--. 1 atguigu atguigu 10485756 8月   6 14:33 00000000000000000000.timeindex
-rw-rw-r--. 1 atguigu atguigu        8 8月   6 14:37 leader-epoch-checkpoint

3.2.2 存储策略

无论消息是否被消费，kafka都会保留所有消息。有两种策略可以删除旧数据：

1）基于时间：log.retention.hours=168

2）基于大小：log.retention.bytes=1073741824

需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

3.2.3 Zookeeper存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JYM19vZO-1655983762858)(file:///C:\Users\MENGFA~1\AppData\Local\Temp\ksohtml16376\wps4.jpg)]

注意：producer不在zk中注册，消费者在zk中注册。

Kafka消费过程分析

kafka提供了两套consumer API：高级Consumer API和低级Consumer API。

3.3.1 高级API

1）高级API优点

高级API 写起来简单

不需要自行去管理offset，系统通过zookeeper自行管理。

不需要管理分区，副本等情况，.系统自动管理。

消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据（默认设置1分钟更新一下zookeeper中存的offset）

可以使用group来区分对同一个topic 的不同程序访问分离开来（不同的group记录不同的offset，这样不同程序读取同一个topic才不会因为offset互相影响）

2）高级API缺点

不能自行控制offset（对于某些特殊需求来说）

不能细化控制如分区、副本、zk等

3.3.2 低级API

1）低级 API 优点

能够让开发者自己控制offset，想从哪里读取就从哪里读取。

自行控制连接分区，对分区自定义进行负载均衡

对zookeeper的依赖性降低（如：offset不一定非要靠zk存储，自行存储offset即可，比如存在文件或者内存中）

2）低级API缺点

太过复杂，需要自行控制offset，连接哪个分区，找到分区leader 等。

3.3.3 消费者组

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4fMU4WL5-1655983762858)(file:///C:\Users\MENGFA~1\AppData\Local\Temp\ksohtml16376\wps5.png)]

消费者是以consumer group消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个partition。在图中，有一个由三个消费者组成的group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。

在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。

3.3.4 消费方式

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

push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

对于Kafka而言，pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞（并且可选地等待到给定的字节数，以确保大的传输大小）。

springboot整合kafka

  1. 添加依赖

    <dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
    <version>2.1.5.RELEASE</version>
</dependency>

  2. 配置application.yml

    • 生产者

      spring:
  kafka:
    bootstrap-servers: 192.168.183.133:9092
    producer:
      retries: 0 # 写入失败时，重试次数。当leader节点失效，一个repli节点会替代成为leader节点，此时可能出现写入失败，
      batch-size: 16384    # 每次批量发送消息的数量,produce积累到一定数据，一次发送
      buffer-memory: 33554432 #produce积累数据一次发送，缓存大小达到buffer.memory就发送数据
      #procedure要求leader在考虑完成请求之前收到的确认数，用于控制发送记录在服务端的持久化，其值可以为如下：
      #acks = 0 如果设置为零，则生产者将不会等待来自服务器的任何确认，该记录将立即添加到套接字缓冲区并视为已发送。在这种情况下，无法保证服务器已收到记录，并且重试配置将不会生效（因为客户端通常不会知道任何故障），为每条记录返回的偏移量始终设置为-1。
      #acks = 1 这意味着leader会将记录写入其本地日志，但无需等待所有副本服务器的完全确认即可做出回应，在这种情况下，如果leader在确认记录后立即失败，但在将数据复制到所有的副本服务器之前，则记录将会丢失。
      #acks = all 这意味着leader将等待完整的同步副本集以确认记录，这保证了只要至少一个同步副本服务器仍然存活，记录就不会丢失，这是最强有力的保证，这相当于acks = -1的设置。
      #可以设置的值为：all, -1, 0, 1
      acks: 1
      key-serializer: org.apache.kafka.common.serialization.StringSerializer    # 指定消息key和消息体的编解码方式
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

    • 消费者

      spring:
  kafka:
    bootstrap-servers: 192.168.183.133:9092
    consumer:
      group-id: testGroupBase   # 指定默认消费者group id --> 由于在kafka中，同一组中的consumer不会读取到同一个消息，依靠groud.id设置组名
      auto-offset-reset: earliest # smallest和largest才有效，如果smallest重新0开始读取，如果是largest从logfile的offset读取。一般情况下我们都是设置smallest
      enable-auto-commit: true # enable.auto.commit:true --> 设置自动提交offset
      auto-commit-interval: 100 #如果'enable.auto.commit'为true，则消费者偏移自动提交给Kafka的频率（以毫秒为单位），默认值为5000。
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer  # 指定消息key和消息体的编解码方式
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer # 指定消息key和消息体的编解码方式

    1. 生产者

          @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;
    //发送消息
    kafkaTemplate.send("item" , "message");

    2. 消费者

      @Configuration
public class KafkaConsumer {
    @Autowired
    private ItemService itemService;
    private ObjectMapper mapper = new ObjectMapper();
    @KafkaListener(topics = {"item"})
    public void listen(ConsumerRecord<String, String> record){
        Optional<String> kafkaMessage = Optional.ofNullable(record.value());
        if (kafkaMessage.isPresent()) {
            String itemStr = kafkaMessage.get();
            try {
                Item item = mapper.readValue(itemStr, Item.class);
                //保存到数据库
                itemService.save(item);
            } catch (IOException e) {
                e.printStackTrace();
            }

        }

    }
}

kafka follower如何与leader同步数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么

ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

kafka中的broker 是干什么的

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等。

kafka producer如何优化打入速度

增加线程

提高 batch.size

增加更多 producer 实例

增加 partition 数

设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；

跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

     Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0—表示不进行消息接收是否成功的确认；
1—表示当Leader接收成功时确认；
-1—表示Leader和Follower都接收成功时确认；
综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2、消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；

High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：

    针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

    针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

消息重复消费及解决参考：https://www.javazhiyin.com/22910.html

为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从而实现的是一种主写主读的生产消费模型。

Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离，也就是说，Follower 副本能够对外提供读服务。

说完这些之后，你可以再给出之前的版本不支持读写分离的理由。

  • 场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。
  • 同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，因此，Follower 与 Leader 存 在不一致性窗口。如果允许读 Follower 副本，就势必要处理消息滞后(Lagging)的问题。

分区 Leader 选举策略有几种?

分区的 Leader 副本选举对用户是完全透明的，它是由 Controller 独立完成的。你需要回答的是，在哪些场景下，需要执行分区 Leader 选举。每一种场景对应于一种选举策略。当前，Kafka 有 4 种分区 Leader 选举策略。

  • OfflinePartition Leader 选举:每当有分区上线时，就需要执行 Leader 选举。所谓的分区上线，可能是创建了新分区，也可能是之前的下线分区重新上线。这是最常见的分区 Leader 选举场景。
  • ReassignPartition Leader 选举:当你手动运行 kafka-reassign-partitions 命令，或者是调用 Admin 的 alterPartitionReassignments 方法执行分区副本重分配时，可能触发此类选举。假设原来的 AR 是[1，2，3]，Leader 是 1，当执行副本重分配后，副本集 合 AR 被设置成[4，5，6]，显然，Leader 必须要变更，此时会发生 Reassign Partition Leader 选举。
  • PreferredReplicaPartition Leader 选举:当你手动运行 kafka-preferred-replica- election 命令，或自动触发了 Preferred Leader 选举时，该类策略被激活。所谓的 Preferred Leader，指的是 AR 中的第一个副本。比如 AR 是[3，2，1]，那么， Preferred Leader 就是 3。
  • ControlledShutdownPartition Leader 选举:当 Broker 正常关闭时，该 Broker 上 的所有 Leader 副本都会下线，因此，需要为受影响的分区执行相应的 Leader 选举。

阐述下 Kafka 中的领导者副本(Leader Replica)和追随者副本 (Follower Replica)的区别

这道题表面上是考核你对 Leader 和 Follower 区别的理解，但很容易引申到 Kafka 的同步 机制上。因此，我建议你主动出击，一次性地把隐含的考点也答出来，也许能够暂时把面试 官“唬住”，并体现你的专业性。

你可以这么回答:Kafka 副本当前分为领导者副本和追随者副本。只有 Leader 副本才能 对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时 准备应聘 Leader 副本。

通常来说，回答到这个程度，其实才只说了 60%，因此，我建议你再回答两个额外的加分 项。

  • 强调 Follower 副本也能对外提供读服务。自 Kafka 2.4 版本开始，社区通过引入新的 Broker 端参数，允许 Follower 副本有限度地提供读服务。
  • 强调 Leader 和 Follower 的消息序列在实际场景中不一致。很多原因都可能造成 Leader 和 Follower 保存的消息序列不一致，比如程序 Bug、网络问题等。这是很严重 的错误，必须要完全规避。你可以补充下，之前确保一致性的主要手段是高水位机制， 但高水位值无法保证 Leader 连续变更场景下的数据一致性，因此，社区引入了 Leader Epoch 机制，来修复高水位值的弊端。关于“Leader Epoch 机制”，国内的资料不是很多，它的普及度远不如高水位，不妨大胆地把这个概念秀出来，力求惊艳一把。

解释下 Kafka 中位移(offset)的作用

在 Kafka 中，每个 主题分区下的每条消息都被赋予了一个唯一的 ID 数值，用于标识它在分区中的位置。这个 ID 数值，就被称为位移，或者叫偏移量。一旦消息被写入到分区日志，它的位移值将不能 被修改。

在 Kafka 中，ZooKeeper 的作用是什么?

这是一道能够帮助你脱颖而出的题目。碰到这个题目，请在心中暗笑三声。

目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖 于 ZooKeeper。

记住，一定要突出“目前”，以彰显你非常了解社区的演进计划。“存放元数据”是指主题 分区的所有数据都保存在 ZooKeeper 中，且以它保存的数据为权威，其他“人”都要与它 保持对齐。“成员管理”是指 Broker 节点的注册、注销以及属性变更，等 等。“Controller 选举”是指选举集群 Controller，而其他管理类任务包括但不限于主题 删除、参数配置等。

不过，抛出 KIP-500 也可能是个双刃剑。碰到非常资深的面试官，他可能会进一步追问你 KIP-500 是做的。一言以蔽之:KIP-500 思想，是使用社区自研的基于 Raft 的共识算法， 替代 ZooKeeper，实现 Controller 自选举。

Kafka中是怎么体现消息顺序性的？

每个分区内，每条消息都有一个offset，故只能保证分区内有序

什么是Controller Broker

在分布式系统中，通常需要有一个协调者，该协调者会在分布式系统发生异常时发挥特殊的作用。在Kafka中该协调者称之为控制器(Controller),其实该控制器并没有什么特殊之处，它本身也是一个普通的Broker，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是：Kafka集群中始终只有一个Controller Broker。

Controller Broker是如何被选出来的

上一小节解释了什么是Controller Broker，并且每台 Broker 都有充当控制器的可能性。那么，控制器是如何被选出来的呢？当集群启动后，Kafka 怎么确认控制器位于哪台 Broker 呢？

实际上，Broker 在启动时，会尝试去 ZooKeeper 中创建 /controller 节点。Kafka 当前选举控制器的规则是：第一个成功创建 /controller 节点的 Broker 会被指定为控制器。

Kafka Controller的作用？

负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作。

Kafka中有那些地方需要选举？这些地方的选举策略又有哪些？

partition leader（ISR），controller（先到先得）

Kafka的那些设计让它有如此高的性能？

分区，顺序写磁盘，0-copy

如果一直消费失败导致消息积压怎么处理？

因为考虑到时消费者消费一直出错的问题，那么我们可以从以下几个角度来考虑：

  1. 消费者出错，肯定是程序或者其他问题导致的，如果容易修复，先把问题修复，让consumer恢复正常消费
  2. 如果时间来不及处理很麻烦，做转发处理，写一个临时的consumer消费方案，先把消息消费，然后再转发到一个新的topic和MQ资源，这个新的topic的机器资源单独申请，要能承载住当前积压的消息
  3. 处理完积压数据后，修复consumer，去消费新的MQ和现有的MQ数据，新MQ消费完成后恢复原状

什么是事务、半事务消息？怎么实现的？

事务消息就是MQ提供的类似XA的分布式事务能力，通过事务消息可以达到分布式事务的最终一致性。

半事务消息就是暂不能投递的消息，发送方已经将消息成功发送到了 MQ 服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半消息

半消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，MQ 服务端通过扫描发现某条消息长期处于“半消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该过程即消息回查

实现原理如下：

  1. 生产者先发送一条半事务消息到MQ
  2. MQ收到消息后返回ack确认
  3. 生产者开始执行本地事务
  4. 如果事务执行成功发送commit到MQ，失败发送rollback
  5. 如果MQ长时间未收到生产者的二次确认commit或者rollback，MQ对生产者发起消息回查
  6. 生产者查询事务执行最终状态
  7. 根据查询事务状态再次提交二次确认

最终，如果MQ收到二次确认commit，就可以把消息投递给消费者，反之如果是rollback，消息会保存下来并且在3天后被删除。

Kafka事务

Kafka事务特性是指一系列的生产者生产消息和消费者提交偏移量的操作在一个事务中，或者说是一个原子操作，生产消息和提交偏移量同时成功或者失败。

Kafka中的事务特性主要用于以下两种场景：

  • **生产者发送多条消息可以封装在一个事务中，形成一个原子操作。**多条消息要么都发送成功，要么都发送失败。
  • **read-process-write模式：将消息消费和生产封装在一个事务中，形成一个原子操作。**在一个流式处理的应用中，常常一个服务需要从上游接收消息，然后经过处理后送达到下游，这就对应着消息的消费和生成。

实现原理如下：

  1. 生产者先发送一条半事务消息到MQ
  2. MQ收到消息后返回ack确认
  3. 生产者开始执行本地事务
  4. 如果事务执行成功发送commit到MQ，失败发送rollback
  5. 如果MQ长时间未收到生产者的二次确认commit或者rollback，MQ对生产者发起消息回查
  6. 生产者查询事务执行最终状态
  7. 根据查询事务状态再次提交二次确认

最终，如果MQ收到二次确认commit，就可以把消息投递给消费者，反之如果是rollback，消息会保存下来并且在3天后被删除。

Kafka事务

Kafka事务特性是指一系列的生产者生产消息和消费者提交偏移量的操作在一个事务中，或者说是一个原子操作，生产消息和提交偏移量同时成功或者失败。

Kafka中的事务特性主要用于以下两种场景：

  • **生产者发送多条消息可以封装在一个事务中，形成一个原子操作。**多条消息要么都发送成功，要么都发送失败。
  • **read-process-write模式：将消息消费和生产封装在一个事务中，形成一个原子操作。**在一个流式处理的应用中，常常一个服务需要从上游接收消息，然后经过处理后送达到下游，这就对应着消息的消费和生成。
jdbcmeng
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SpringBoot整合kafka客户端实战（核心API——Admin）
JAVA求生之路——博主406766467
06-10 402
感谢您抽出时间来阅读本文章，期待您的点赞和评论互动！ 二、创建Admin测试类 2.1 创建topic 测试结果 测试结果 2.4 查看Topic详情 2.5 增加分区数量
SpringBoot Kafka 整合使用及安装教程
08-25
SpringBoot Kafka 整合使用及安装教程 SpringBoot Kafka 整合使用及安装教程是将 SpringBoot 和 Kafka 两个技术栈进行整合，实现消息队列的处理。本文将详细介绍 SpringBoot Kafka 的整合使用及安装教程，包括项目...
SpringBoot整合kafka
06-14
SpringBoot整合kafka代码，两个工程 一个消费者 一个生产者，利用定时任务。很简洁代码。欢迎大家下载哦。可参考这篇文章代码哦。https://blog.csdn.net/weixin_39984161/article/details/91986809
SpringBoot2.X项目搭建整合Kafka客户端Demo(初级入门四)
点滴记忆，分享成长之路
12-18 1148
SpringBoot2.X项目搭建整合Kafka客户端 创建topic 删除topic 查看topic详情
Kafka的安装配置以及与SpringBoot的集成
qq_31456173的博客
03-03 326
本文阐述了Linux下Kafka的安装部署以及Kafka的基本使用，如何在SpringBoot中集成Kafka
java——spring boot集成kafka——spring boot集成kafka
小白龙白龙马的博客
04-02 195
引入依赖： <dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> </dependency> 编写配置文件： erver: port: 8080...
springboot - 2.7.3版本 - （七）整合Kafka
09-30
在`springboot-kafka`目录下，可能包含了一个示例项目，你可以通过导入IDE进行编译和运行，以了解Spring Boot与Kafka集成的实践操作。 通过以上步骤，你已经掌握了如何在Spring Boot 2.7.3中集成Apache Kafka的基本...
springboot整合kafka的发布/消费demo项目源码
08-18
在本文中，我们将深入探讨如何将Spring Boot与Apache Kafka整合，以便实现发布/消费消息队列模式。Apache Kafka是一款高效、可扩展且分布式的消息中间件，而Spring Boot则是一个简化了Spring应用程序开发的框架。...
springboot整合kafka
06-23
SpringBoot整合Kafka是现代Java应用中常见的数据流处理方式，Kafka作为一个高吞吐、低延迟的消息中间件，常用于大数据实时处理、日志收集等场景。SpringBoot的轻量级特性使得与Kafka的集成变得简单易行。本文将深入...
SpringBoot整合kafka及ProtoBuf实现跨平台跨语言的信息交互
10-28
在SpringBoot中整合其他组件如Kafka，可以让我们的微服务架构更加灵活和高效。 Kafka是由Apache开发的一款高吞吐量的分布式消息队列系统，它作为消息中间件，可以处理大量实时数据流。Kafka的主要特点包括：高并发...
Kafka的Java客户端访问以及整合SpringBoot
业精于勤，荒于嬉
08-01 594
一、基本使用 以2.4.1 release版本为例—kafka_2.11-2.4.1.tgz，其中2.11是scala的版本，2.4.1是kafka的版本 0.准备 Kafka运行在JVM上，因此需要先安装JDK Kafka依赖zookeeper，因此需要先安装并启动zookeeper（不安装也可，Kafka中会自带zookeeper，推荐自行安装） 1.下载解压 解压完成后，可以使用bin目录下的脚本对Kafka进行下列操作，此处略过。 2.修改配置config/server.properties 修改b
Spring Boot Kafka 环境安装
fishpro的博客
04-26 475
在mac环境下安装 1 使用 brew install kafka 在mac环境下，直接使用 brew install kafka 安装即可。安装过程中出现的问题 1.1 问题：总是停在 Updating Homebrew… 这跟安装 kafka没有关系，是mac系统问题，由于众所周知的问题，brew的更新源地址不能直接更新解决方案有两个 1.1.1 设置brew不更新 export HOMEBR...
SpringBoot整合Kafka
沮丧的南瓜
08-31 1万+
现在大多数公司都是使用SpringBoot技术，所以使用SpringBoot整合Kafka是比较重要的。接下来我们就来使用SpringBoot整合Kafka。 一、项目构建 我们首先创建一个基于maven的SpringBoot项目. 1、pom依赖 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.
spring和springboot集成kafka
thunder liu 的博客
11-03 327
spring和springboot集成kafka 1.kafka配置 一般组件支持的配置都会再*Config.Java中描述，其中有可配置项、可配置项描述、默认配置值等信息，而kafka的配置类为：ProducerConfig.java #kafka服务器的地址和端口，eg：127.0.0.1:9092 bootstrap.servers #控制客户端如何使用DNS查找 client.dns.lookup #阻塞等待元数据的最长时间；ps：数据首次发送到topic时，需要先获取改topic的元数据，
在Spring Boot微服务集成Kafka客户端(spring-kafka)操作Kafka
zhangbeizhen18的博客
06-17 4200
记录：457 场景：在Spring Boot微服务集成Kafka客户端spring-kafka-2.8.2操作Kafka。使用Spring封装的KafkaTemplate操作Kafka生产者Producer。使用Spring封装的@KafkaListener操作Kafka的消费者Consumer。
SpringBoot中使用Apache Kafka客户端（消费者）
最新发布
fxtxz2的专栏
09-24 343
SpringBoot中使用Apache Kafka客户端还是提简单的，相比Spring Cloud Stream Kafka流处理框架而言。
【Kafka】2.在SpringBoot中使用官方原生java版Kafka客户端
yuhuofei的草屋
08-14 1160
使用官方原生java版Kafka客户端
Apache Kafka Spring 集成
u013433591的博客
01-02 716
Apache Kafka Spring 集成、@KafkaListener 消息监听、消息过滤
Springboot 配置使用 Kafka
热门推荐
friggly的博客
02-22 1万+
As we all know，当今世界最流行的消息中间件有 RabbitMq、RocketMq、Kafka，其中，应用最广泛的是 RabbitMq，RocketMq 是阿里巴巴的产品，性能超过 RabbitMq，已经经受了多年的双11考验，但是怕哪天阿里不维护了，用的人不多，Kafka 是吞吐量最大的一个，远超前两个，支持事务、可保证消息的不丢失（网上说的事务和消息可靠性不支持是说的旧版，2以后就开始支持了），对比来讲，Kafka相对于前两个，只有一个劣势，不太支持延时队列，其他方面都要优于它们。
kafka如何整合至springboot
04-26
要将Kafka整合到Spring Boot应用程序中，首先需要在pom.xml文件中添加Kafka客户端依赖项。然后，需要定义一个Kafka生产者和一个Kafka消费者。在Spring Boot应用程序中，可以使用@EnableKafka注释启用Kafka集成，并...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值