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端运行该命令):

bin/kafka-broker-api-version.sh --bootstrap-server localhost:9092

下面两张图分别表示查看0.10.2.0和0.10.0.1的broker所支持各协议的版本范围,注意我标红了FETCH请求以示区别:

                

  左边的图连接的是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服务器的交互了。

时间: 2024-10-03 17:57:26

Kafka协议兼容性改进的相关文章

Kafka 协议实现中的内存优化【转】

Kafka 协议实现中的内存优化 Jusfr 原创,转载请注明来自博客园 Request 与 Response 的响应格式 Request 与 Response 都是以 长度+内容 形式描述, 见于 A Guide To The Kafka Protocol Request 除了 Size+ApiKey+ApiVersion+CorrelationId+ClientId 这些固定字段, 额外的 RequestMessage 包含了具体请求数据: Request => Size ApiKey Ap

Kafka 协议实现中的内存优化

Kafka 协议实现中的内存优化 Kafka 协议实现中的内存优化 Jusfr 原创,转载请注明来自博客园 Request 与 Response 的响应格式 Request 与 Response 都是以 长度+内容 形式描述, 见于 A Guide To The Kafka Protocol Request 除了 Size+ApiKey+ApiVersion+CorrelationId+ClientId 这些固定字段, 额外的 RequestMessage 包含了具体请求数据: Request

HTTP2协议主要改进点

1.改成二进制协议,每次传输二进制帧,帧有以下几个字段 类型type,长度length,flag,StringID流标志,Payload负载,最基础的两种类型HEAD类型和DATA类型 2.多路复用,可以在一个连接上,同时传输多个数据流,每个流的传输顺序是固定的,按先后到达拼接 3.支持优先级,通过权重 4.支持重置中断,在HTTP/1.1中,如果一个请求发出去了,在没有发送完的情况下,是不好取消的,只能断开这次的TCP连接,但是断开重连有有点费时,HTTP2可以发送一个RST_STREAM帧,

Kafka 0.8协议

介绍 概述 预备知识 网络 分区和引导 分区策略 批量处理 版本控制和兼容性 协议 Protocol Primitive Types Notes on reading the request format grammars Common Request and Response Structure Requests Responses Message sets Compression The APIs Metadata API Metadata Request Metadata Response

Kafka与RabbitMQ、ActiveMQ协议区别

对于Kafka与RabbitMQ.ActiveMQ协议,它们具体的区别如下: activemq:        activemq支持主从复制.集群.但是集群功能看起来很弱,只有failover功能,即我连一个失败了,可以切换到其他的broker上.这一点貌似不太科学.假设有三个broker,其中一个上面没有consumer,但另外两个挂了,消息会转到这个上面来,堆积起来.看样子activemq还在升级中.        activemq工作模型比较简单.只有两种模式 queue,topics r

SRUP协议增强和改进

SRUP协议扩展和增强 Andrew John Poulter Steven J. Johnston and Simon J. Cox 英国南安普敦大学环境和工程系 摘要:这篇论文基于此前一篇介绍安全远程升级协议(SRUP)的论文.SRUP是一种应用于物联网命令和控制应用的安全通信协议,它基于MQTT协议.这篇论文在原有论文的基础上增加了一系列新的信息类型,提升了协议的能力.我们还探讨了网络中物理设备与逻辑设备标识对应问题,并在协议中提出了解决机制. 1.引言 在我们之前的论文中介绍了SRUP协

KIP-32 Add timestamps to Kafka message

通过KIP32,Kafka的每条消息都加进了时间戳,这个KIP在0.10.0.0被加入. 说到“时间”,先贴张图,娱乐一下(如果对星球大战系列电影不熟的话,请自动略过……) 这个KIP的文档在 KIP-32 - Add timestamps to Kafka message 下面贴一下这个KIP的关键部分,俺的注解部分用灰色的字标识. Motivation 动机 This KIP tries to address the following issues in Kafka. Log retent

Kafka 消息队列系列之分布式消息队列Kafka

介绍 ApacheKafka®是一个分布式流媒体平台.这到底是什么意思呢?我们认为流媒体平台具有三个关键功能:它可以让你发布和订阅记录流.在这方面,它类似于消??息队列或企业消息传递系统.它允许您以容错方式存储记录流.它可以让您在发生记录时处理记录流.什么是卡夫卡好?它被用于两大类的应用程序:构建可在系统或应用程序之间可靠获取数据的实时流数据管道构建实时流应用程序,可以转换或响应数据流要了解卡夫卡如何做这些事情,让我们深入探索卡夫卡的能力.首先几个概念:Kafka作为一个或多个服务器上的集群运行

TCP传输协议

1.TCP中一些名词解释 (1)MSS(maximum segment size) TCP的最大报文段大小,在TCP报文段中有一个16位的部分用于放置该值,因此最大为65535,可以利用setsockopt() 和getsockopt设置和获取TCP_MAXSEG来影响MSS: (2)MSL(maximum segment lifetime) IP报文段能在网络中存在的最长时间,这个是系统级的参数,没有接口修改,windows上可以通过注册表修改,通常为2分钟,最低为30秒,linux上面没法修