kafka:broker、client、spring-kafka版本间的关系

本文介绍了Kafka从0.10.2.0开始的协议兼容性改进,用户如何通过检查broker支持的协议版本来确保高版本client请求的顺利执行,以及Java client的自动适配。重点在于简化与旧版Kafka服务器的交互。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

broker、client:(Kafka双向兼容)

 在Kafka 0.10.2.0之前,Kafka服务器端和客户端版本之间的兼容性是“单向”的,即高版本的broker可以处理低版本client的请求。反过来,低版本的broker不能处理高版本client的请求。由于升级client要远比升级broker简单得多,因此这个限制给很多用户带来了麻烦,甚至有很多人都不愿意去升级broker版本——毕竟无downtime的情况下正确升级Kafka服务器是个不小的挑战。

    自0.10.2.0版本开始,社区对这个问题进行了优化——对于低版本broker + 高版本client(0.10.2.0)的环境而言,现在用户可以运行命令先查看当前broker支持的协议版本,然后再选择broker支持的最高版本封装请求即可。命令格式如下(在client端运行该命令):

                

    左边的图连接的是0.10.2.0版本的broker,可以看到该版本的Kafka服务器支持的FETCH请求版本范围是0到3,默认使用3;而右边的图连入的是0.10.0.1的Kafka,它只支持0~2版本的FETCH请求。因此你在编写客户端程序时需要根据这张表来确认broker支持的请求的最高版本,这样就间接实现了“低broker处理高client请求”的兼容性目标。

    考虑到Java版本的client已经被广大用户直接使用了,社区也改写了Java clients底层的网络客户端代码,里面会自动地判断连接的broker端所支持client请求的最高版本,并自动创建合乎标准的请求。因此,对于FETCH请求和PRODUCE请求而言, 用户不用担心需要自己实现这些细节。

    总之,自0.10.2.0之后用户可以简单地升级client端代码到这个版本就可以很容易地实现与低版本Kafka服务器的交互了。

broker、client的结论:

安装的kafka_2.11-2.4.1,版本为2.4.1,标准的要是用的client版本为:

<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-clients</artifactId>
    <version>2.4.1</version>
</dependency>

可以使用低版本的client去请求,比如使用

也可以选择broker支持的最高版本(这个还没有测试)

 

client、spring-kafka:

比较新的kafka-clients可以与比较老的spring-kafka进行通信,比如:

                <!-- kafka交互式查询使用的数据库 -->
		<dependency>
			<groupId>org.springframework.kafka</groupId>
			<artifactId>spring-kafka</artifactId>
			<version>1.1.1.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-streams</artifactId>
			<version>2.2.0</version>
		</dependency>
		<dependency>
			<groupId>org.rocksdb</groupId>
			<artifactId>rocksdbjni</artifactId>
			<version>5.9.2</version>
		</dependency>
		<dependency>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
			<version>2.2.0</version>
		</dependency>

备注:我这边安装的kafka_2.11-2.4.1,使用的是上面的配置与kafka进行通信

 

1/kafka是一个分布式的消息缓存系统 2/kafka集群中的服务器都叫做broker 3/kafka有两类客户端,一类叫producer(消息生产者),一类叫做consumer(消息消费者),客户端和broker服务器之采用tcp协议连接 4/kafka中不同业务系统的消息可以通过topic进行区分,而且每一个消息topic都会被分区,以分担消息读写的负载 5/每一个分区都可以有多个副本,以防止数据的丢失 6/某一个分区中的数据如果需要更新,都必须通过该分区所有副本中的leader来更新 7/消费者可以分组,比如有两个消费者组A和B,共同消费一个topic:order_info,A和B所消费的消息不会重复 比如 order_info 中有100个消息,每个消息有一个id,编号从0-99,那么,如果A组消费0-49号,B组就消费50-99号 8/消费者在具体消费某个topic中的消息时,可以指定起始偏移量 每个partition只能同一个group中的同一个consumer消费,但多个Consumer Group可同时消费同一个partition。 n个topic可以被n个Consumer Group消费,每个Consumer Group有多个Consumer消费同一个topic Topic在逻辑上可以被认为是一个queue,每条消费都必须指定它的Topic,可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高,物理上把Topic分成一个或多个Partition,每个Partition在物理上对应一个文件夹,该文件夹下存储这个Partition的所有消息和索引文件。若创建topic1和topic2两个topic,且分别有13个和19个分区 Kafka的设计理念之一就是同时提供离线处理和实时处理。根据这一特性,可以使用Storm这种实时流处理系统对消息进行实时在线处理,同时使用Hadoop这种批处理系统进行离线处理,还可以同时将数据实时备份到另一个数据中心,只需要保证这三个操作所使用的Consumer属于不同的Consumer Group即可。
### 安装和配置Kafka #### 下载并解压Kafka 为了在Linux上安装Kafka,首先需要下载官方发布的压缩包。可以从Apache Kafka官方网站获取最新版本的二进制分发版。 ```bash wget https://downloads.apache.org/kafka/3.0.0/kafka_2.13-3.0.0.tgz tar -xzf kafka_2.13-3.0.0.tgz cd kafka_2.13-3.0.0/ ``` #### 配置ZooKeeper 因为Kafka依赖于ZooKeeper来管理集群状态和其他元数据信息,在启动Kafka之前应该先确保ZooKeeper正在运行。如果尚未安装ZooKeeper,则需按照官方文档完成其安装过程[^2]。 #### 修改Kafka配置文件 进入`config/server.properties`编辑必要的参数: ```properties broker.id=0 port=9092 host.name=localhost log.dirs=/tmp/kafka-logs zookeeper.connect=localhost:2181 listeners=PLAINTEXT://:9092 advertised.listeners=PLAINTEXT://localhost:9092 ``` 以上设置指定了Broker ID、监听端口、主机名、日志存储位置以及连接至本地ZooKeeper实例的方式。对于多节点集群来说,应当调整这些值以匹配各个机器的具体情况[^3]。 #### 启动服务 通过执行脚本来分别启动ZooKeeper和Kafka Broker: ```bash # Start ZooKeeper first bin/zookeeper-server-start.sh config/zookeeper.properties & # Then start the Kafka broker bin/kafka-server-start.sh config/server.properties & ``` 此时可以通过命令查看当前可用的主题列表验证是否成功启动了Kafka消息队列系统: ```bash sh bin/kafka-topics.sh --list --bootstrap-server localhost:9092 ``` ### 将KafkaSpring Cloud集成 当完成了上述基础搭建之后,就可以着手准备让Spring Cloud应用程序能够利用Kafka作为消息总线的一部分了。这通常涉及到两个方面的工作——一个是配置中心(Config Server),另一个是客户端应用(Config Client)。 #### 设置Spring Cloud Config Server支持Kafka Bus 为了让配置服务器能接收到来自Git仓库变更的通知并通过Kafka广播出去,需要引入额外的支持库并在application.yml中指定相应属性: ```yaml spring: cloud: bus: enabled: true trace: enabled: false refresh: enabled: true kafka: id: ${vcap.application.instance_id:${spring.application.name}:${random.uuid}} destinations: output trust-certificate: classpath:/certificates/truststore.jks client-id: configServer brokers: localhost:9092 ``` 这段YAML片段启用了Spring Cloud Bus功能,并设置了用于发送事件的目标主题名称以及其他一些安全性和性能优化选项[^1]。 #### 更新Spring Cloud Config Clients 同样地,在每一个想要订阅配置更新通知的应用程序里也需要做类似的改动。主要是在pom.xml或build.gradle里面加入对`spring-cloud-starter-bus-kafka`模块的依赖声明,同时也要适当修改各自的application.yml文件以便正确接入到已有的Kafka集群当中去[^4]。 最后一步便是重启所有的微服务组件使得新的配置生效,这样每当有新的提交推送到关联的GitHub/GitLab项目时,就会触发一次全局范围内的动态刷新流程,从而实现了自动化运维的目的。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值