Kafka通讯协议指南.docx

《Kafka通讯协议指南.docx》由会员分享，可在线阅读，更多相关《Kafka通讯协议指南.docx（72页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、Kafka 通讯协议指南中英文术语比照为避开歧义，大局部的英文术语找不到适宜中文对应时都保持英 文原文，Kafka 中一些根本术语也使用英文，其中一局部通过括号参与英文原文；另外，文中可能使用到的中英文术语包括但不限于：英文Metadata offset Comsumer中文元数据偏移量消费者Comsumer Group 消费者组Topic主题API接口Coordinator协调器1 简介此文档涵盖了 Kafka 0.8 及之前版本的通讯协议实现。其目的是供给一个包含的可恳求的协议及其二进制格式以及如何正确使用他们来 实现一个客户端的通讯协议文档。本文假设您已经了解了 Kafka 根本的设计以

2、及术语。0.7 和更早的版本所使用的协议与此类似，但我们期望通过一次性地斩断兼容性，以便清理原有设计上的沉疴，并且泛化一些概念。假设遇到无法理解的状况，请参照英文原文2 概述卡夫卡协议是相当简洁的，只有六个核心的客户端恳求的API：1. 元数据Metadata 描述可用的 brokers，包括他们的主机和端口信息，并给出了每个 broker 上分别存有哪些分区；2. 发送Send 发送消息到 broker；3. 猎取Fetch 从 broker 猎取消息，其中，一个猎取数据， 一个猎取集群的元数据，还有一个猎取 topic 的偏移量信息；4. 偏移量Offsets 猎取给定 topic 的分区

3、的可用偏移量信息；5. 偏移量提交Offset Commit 提交消费者组Comsumer Group的一组偏移量；6. 偏移量猎取Offset Fetch 猎取一个消费者组的一组偏移量；上述的 API 都将在下面具体说明。此外，从 0.9 版本开头，Kafka 支持为消费者和Kafka 连接进展分组治理。客户端API 包括五个恳求：1. 分组协调者 GroupCoordinator 用来定位一个分组当前的协调者。2. 参与分组JoinGroup 成为某一个分组的一个成员，当分组不存在没有一个成员时创立分组。3. 同步分组SyncGroup 同步分组中全部成员的状态例如分发分区安排信息(Par

4、tition Assignments)到各个组员。4. 心跳Heartbeat 保持组内成员的活泼状态。5. 离开分组LeaveGroup 直接离开一个组。最终，有几个治理 API，可用于监控/治理的卡夫卡集群 KIP-4 完成时，这个列表将增长：1. 描述消费者组DescribeGroups 用于检查一组群体的当前状态如：查看消费者分区安排。2. 1.列出组ListGroups 列出某一个 broker 当前治理的全部组3 开头网络Kafka 使用基于 TCP 的二进制协议。该协议定义了全部 API 的恳求及响应消息。全部消息都是有长度限制的，并且由后面描述的根本 类型组成。客户端启动的 s

5、ocket 连接，并且写入恳求的消息序列和读回相应的响应消息。连接和断开时均不需要握手消息。假设保持你保持长连 接，那么 TCP 协议本身将会节约很多 TCP 握手时间，但假设真的重建立连接，那么代价也相当小。客户可能需要维持到多个 broker 的连接，由于数据是被分区的， 而客户端需要和存储这些分区的 broker 效劳器进展通讯。固然，一般而言，不需要为单个效劳端和单个客户端间维护多个连接即连接池 技术。效劳器的保证单一的 TCP 连接中，恳求将被挨次处理，响应也将按该挨次返回。为保证 broker 的处理恳求的挨次，单个连接同时也只会处理一个恳求指令。请留意，客户端可以也应当使用非堵塞

6、 IO 实现恳求流水线，从而实现更高的吞吐量。也就是说，客户可以在等 待上次恳求应答的同时发送下个恳求，由于待完成的恳求将会在底层 操作系统套接字缓冲区进展缓冲。除非特别说明，全部的恳求是由客 户端启动，并从效劳器猎取到相应的响应消息。效劳器能够配置恳求大小的最大限制，超过这个限制将导致socket 连接被断开。分区和引导Partitioning and bootstrappingKafka 是一个分区系统，所以不是全部的效劳器都具有完整的数据集。主题(Topic)被分为 P预先定义的分区数量个分区，每个分区被复制 N复制因子份，Topic Partition 依据挨次在“提交日志” 中编号为

7、 0，1，P。全部具有这种特性的系统都有一个如何制定某个特定数据应当被安排给哪个特定的分区的问题。Kafka 中它由客户端直接把握安排策略， broker 则没有特别的语义来打算消息公布到哪个分区。相反，生产者直接将消息发送到一个特定的分区，提取消息时，消费者也直接从某个特定的分区猎取。假设两个生产者要使用一样的分区方案，那么他们必需用同样的方法来计算 Key 到分区映射关系。这些公布或猎取数据的恳求必需发送到指定分区中作为 leader 的broker。此条件同时也会由 broker 保证，发送到不正确的 broker 的恳求将会返回 NotLeaderForPartition 错误代码后文

8、所描述的。那么客户端如何找出哪些主题存在，他们有什么分区，以及这些分区被哪些 broker 存取，以便它可以直接将恳求发送到所在的主机？ 这个信息是动态的，因此你不能只是供给每个客户端一些静态映射文 件。全部的 Kafka broker 都可以答复这个描述集群的当前状态的数据恳求：有哪些主题，这些主题都有多少分区，哪个 broker 是这些分区的 Leader，以及这些 broker 主机的地址和端口信息。换句话说，客户端只需要找到一个 broker，broker 将会告知客户端全部其他存在的 broker，以及这些 broker 上面的全局部区。这个broker 本身也可能会掉线，因此客户端

9、实现的最正确做法是保存两个或三个 broker 地址，从而来引导列表。用户可以选择使用负载均衡器或只是静态地配置两个或三个客户的 Kafka 主机。客户并不需要轮询地查看集群是否已经转变；它可以等到它接收 到所用的元数据是过时的错误信息时一次性更元数据。这中错误有 两种形式：1一个套接字错误指示客户端不能与特定的 broker 进展通信， 2恳求响应说明该broker 不再是其恳求数据分区的Leader 的错误。1. 轮询“起始”Kafka 的 URL 列表，直到我们找到一个我们可以连接到的 broker。猎取集群元数据。2. 处理猎取数据或者存储消息恳求，依据这些恳求所发送的主题和分区，将这

10、些恳求发送到适宜的 broker。3. 假设我们得到一个适当的错误 (显示元数据已经过时时 )，刷元数据，然后再试一次。分区策略Partitioning Strategies上面提到消息的分区安排是由生产者客户端把握，那么，为什么要把这个功能被暴露给最终用户？在 Kafka 中，这样分区有两个目的：1. 它平衡了 broker 的数据和恳求负载2. 它允很多个消费者之间处理分发消息的同时，能够维护本地状态， 并且在分区中维持消息的挨次。 我们称这种语义的分区semantic partitioning。对于给定的使用场景下，你可能只关心其中的一个或两个。为了实现简洁的负载均衡，一个简洁的策略是客

11、户端公布消息是 对全部 broker 进展轮询恳求(round robin requests)。另一种选择， 在那些生产者比消费者多的场景下，给每个客户机随机选择并公布消 息到该分区。后一种的策略能够使用少得多的TCP 连接。语义分区是指使用关键字(key)来打算消息安排的分区。例如，假设你正在处理一个点击消息流时，可能需要通过用户 ID 来划分流，使得特定用户的全部数据会被单个消费者消费。要做到这一点，客户端 可以实行与消息相关联的关键字，并使用关键字的某个Hash 值来选择的传送的分区。批处理Batching我们的 API 鼓舞将小的恳求批量处理以提高效率。我们觉察这能格外显著地提升性能。

12、我们两个用来发送消息和猎取消息的API，总是以一连串的消息工作，而不是单一的消息，从而鼓舞批处理操作。聪 明的客户端可以利用这一点，并支持“异步”操作模式，以此进展批 处理哪些单独发送的消息，并把它们以较大的块进展发送。我们再进 一步允许跨多个主题和分区的批处理，所以生产恳求可能包含追加到 很多分区的数据，一个读取恳求可以一次性从多个分区提取数据的。固然，假设他们宠爱，客户端实现者可以选择无视这一点，全部消息一次都发送一个。版本和兼容性Versioning and Compatibility该协议的目的要到达在向后兼容的根底上渐进演化。我们的版本 是基于每个 API 根底之上，每个版本包括一个

13、恳求和响应对。每个恳求包含 API Key，里面包含了被调用的API 标识，以及表示这些恳求和响应格式的版本号。这样做的目的是允许客户端执行相应特定版本的恳求。目标主要是为了在不允许停机的环境下进展更，这种环境下，客户端和效劳器不能一次性都切换所使用的 API。效劳器将拒绝它不支持的版本的恳求，并始终返回它期望收到的能够完成恳求响应的版本的协议格式。预期的升级路径方式是，功能将首先部署到效劳器老客户端无法完全利用他们的功能，然后随着的客户端的部署，这些功能将逐步被利用。目前，全部版本基线为0，当我们演进这些API 时，我们将分别显示每个版本的格式。4 通讯协议The Protocol协议根本数

14、据类型Protocol Primitive TypesThe protocol is built out of the following primitive types. 该协议是建立在以下根本类型之上。 定长根本类型Fixed Width Primitives int8, int16, int32, int64 不同精度(以 bit 数区分)的带符号整数，以大端Big Endiam方式存储. 变长根本类型Variable Length Primitives bytes, string 这些类型由一个表示长度的带符号整数N 以及后续 N 字节的内容组成。长度假设为 -1 表示空 null.

15、string 使用int16 表示长度，bytes 使用 int32. 数组Arrays 这个类型用来处理重复的构造体数据。他们总是由一个代表元素个数 int32 整数 N，以及后续的 N 个重复构造体组成，这些构造体自身是有其他的根本数据类型组成。我们后面会用 BNF 语法呈现一个foo 的构造体数组foo恳求格式语法要点Notes on reading the request format grammars后面的 BNF 精准地以上下文无关的语法呈现了恳求和响应的二进制格式。每个 API 都会一起给出恳求和响应，以及全部的子定义sub-definitions。BNF 使用没有经过缩写的便于

16、阅读的名称比方我使用一个符号化了得名称来定义了一个生产者错误码，即便它只是 int16 整数。一般在 BNF 中，一个序列表示一个连接，所以下面给出的 MetadataRequest 将是一个含有 VersionId，然后 clientId， 然后 TopicNames 的阵列每一个都有其自身的定义。自定义类型一般使用驼峰法拼写，根本类型使用全小写方式乒协。当存在多中可 能的自定义类型时，使用|符号分割，并且用括号表示分组。顶级定义不缩进，后续的子局部会被缩进。一般的恳求和响应格式Common Request and Response Structure全部恳求和响应都从以下语法起源，其余的会

17、在本文剩下局部中进展增量描述：1.2. RequestOrResponse ResponseMessage)3.4.5. Size = int32 6.域FIELD=Size(RequestMessage|描述MessageSize MessageSize 域给出了后续恳求或响应消息的字节 (bytes)长度。客户端可以先读取 4 字节的长度N，然后读取并解析后续的 N字节恳求内容。恳求Requests全部恳求都具有以下格式：1.2. RequestMessage =ApiKey ClientId RequestMessage3.4.5. ApiKey = int16 6.7.8. ApiVe

18、rsion = int16 9.10.11.CorrelationId = int32 12.ApiVersion CorrelationId13.14.15.ClientId = string16.17.RequestMessage=MetadataRequest|ProduceRequest|FetchRequest|OffsetRequest|OffsetCommitRequest | OffsetFetchRequest18.域FIELD ApiKeyApiVersion描述这是一个表示所调用的 API 的数字 id即它表示是一个元数据恳求？生产恳求？猎取恳求等.这是该 API 的一个

19、数字版本号。我们为每个 API 定义一个版本号，该版本号允许效劳器依据版本号正确地解释恳求内容。响应消息也始终对应于所述恳求的版本的格式。目前全部 API 的支持版本为 0。CorrelationId 这是一个用户供给的整数。它将会被效劳器原封不动地回传给客户端。用于匹配客户机和效劳器之间的恳求和响应。这是为客户端应用程序的自定义的标识。用户可以使用他们宠爱的任何标识符，他们会被用在记录错误时，监测统计信息等ClientId场景。例如，你可能不仅想要监视每秒的总体恳求，还要依据客户端应用程序进展监视，那它就可以被用上其中每一个都将驻留在多个效劳器上。这个ID 作为特定的客户端对全部的恳求的规律

20、分组。下面我们就来描述各种恳求和响应消息。响应Responses1.2. Response = CorrelationId ResponseMessage 3.4.5. CorrelationId = int32 6.7.8. ResponseMessage=MetadataResponse|ProduceResponse|FetchResponse|OffsetResponse|OffsetCommitResponse | OffsetFetchResponse9.域FIELD描述CorrelationId 效劳器传回给客户端它所供给用作关联恳求和响应消息的整数。全部响应都是与恳求成对匹配例

21、如，我们将发送回一个元数据恳求，会得到一个元数据响应。消息集Message sets生产和猎取消息指令恳求共享同一个消息集构造。在 Kafka 中， 消息是由一个键值对以及少量相关的元数据组成。消息集学问一个有 偏移量和大小信息的消息序列。这种格式正好即可用于在 broker 上的磁盘上存储，也可用在线上数据交换。消息集也是 Kafka 中的压缩单元，我们也允许消息递归包含压缩消息从而允许批量压缩。留意, 在通讯协议中，消息集之前没有类似的其他数组元素的int32。1.2. MessageSet = Offset MessageSize Message 3.4.5. Offset = int6

22、4 6.7.8. MessageSize = int32 9.消息格式1.2. Message = Crc MagicByte Attributes Key Value 3.4.5. Crc = int32 6.7.8. MagicByte = int8 9.10.11.Attributes = int8 12.13.14.Key = bytes 15.16.17.18.域FIELDOffsetCrc MagicByteAttributes KeyValueValue = bytes描述这是在 Kafka 中作为日志序列号使用的偏移量。当生产者发送消息，实际上它并不知道偏移量的具体值，这时候它

23、可以填写任意值。Crc 是的剩余消息字节的CRC32 值。broker 和消费者可用来检查信息的完整性。这是一个用于允许消息二进制格式的向后兼容演化的版本 id。当前值是 0。这个字节保存有关信息的元数据属性。最低的 2 位包含用于消息的压缩编解码器。其他位应当被设置为 0。Key 是一个可选项，它主要用来进展指派分区。Key 可以为 null.Value 是消息的实际内容，类型是字节数组。Kafka 支持本身递归包含，因此本身也可能是一个消息集。消息可以为 null。压缩CompressionKafka 支持压缩多条消息以提高效率，固然，这比压缩一条原始消息要来得简洁。由于单个消息可能没有足

24、够的冗余信息以到达良好的 压缩比，压缩的多条信息必需以特别方式批量发送固然，假设真的 需要的话，你可以自己压缩批处理的一个消息。要被发送的消息被 包装未压缩在一个 MessageSet 构造中，然后将其压缩并存储在一个单一的“消息”中，一起保存的还有相应的压缩编解码集。接收 系统通过解压缩得到实际的消息集。外层 MessageSet 应当只包含一个压缩的“消息”详情见 Kafka-1718。卡夫卡目前支持一下两种压缩编解码器编号：压缩算法COMPRESSION 编码器编号CODECNone0GZIP1Snappy2接口(The APIs)本节将给出每个 API 的用法、二进制格式，以及它们的字

25、段的含义的细节。元数据接口Metadata API这个 API 答复以下问题： 存在哪些主题Topic？ 每个主题有几个分区Partition？ 每个分区的 Leader 分别是哪个 broker？ 这些 broker 的地址和端口分别是什么？这是唯一一个能发往集群中任意一个 broker 的恳求消息。由于可能有很多主题，客户端可以给一个的可选主题名列表，以便只返回主题元数据的一个子集。返回的元数据是在分区级别，为了便利和以避开冗余，以主题为 组集中在一起。每个分区的元数据中包含了 leader 以及全部副本以及正在同步的副本的信息。留意: 假设 broker 配置中设置了”auto.crea

26、te.topics.enable”, 主题元数据恳求将会以默认的复制因子和默认的分区数为参数创立主 题。主题元数据恳求Topic Metadata Request1.2. TopicMetadataRequest = TopicName 3.4.5. TopicName = string 6.域FIELD描述TopicName要猎取元数据的主题数组。 假设为空，就返回全部主题的元数据元数据反响Metadata Response响应包含的每个分区的元数据，这些分区元数据以主题为组组装 在一起。该元数据以 broker id 来指向具体的 broker。每个 broker 有一个地址和端口。1.2

27、. MetadataResponse = BrokerTopicMetadata 3.4.5. Broker = NodeId Host Port (any number of brokers may be returned)6.7.8. NodeId = int32 9.10.11.Host = string 12.13.14.Port = int32 15.16.17.TopicMetadata=TopicErrorCodeTopicNamePartitionMetadata18.19.20.21.TopicErrorCode = int1622.23.PartitionMetadata=

28、PartitionErrorCodePartitionId Leader Replicas Isr 24.25.26.PartitionErrorCode = int16 27.28.29.PartitionId = int32 30.31.32.Leader = int32 33.34.35.Replicas = int32 36.37.38.39.域FIELDLeaderIsr = int32描述该分区作为 Leader 节点的 Kafka broker id。假设在一个 Leader 选举过程中，没有 Leader 存在，这个 id 将是-1。Replicas该分区中，其他活着的作为 s

29、lave 的节点集合。Isr Broker副本集合中，全部处在与 Leader 跟随“caught up”，表示数据已经完全复制到这些节点状态的子集kafka broker 节点的 id, 主机名, 端口信息可能的错误码Possible Error Codes UnknownTopic (3) LeaderNotAvailable (5) InvalidTopic (17) TopicAuthorizationFailed (29)生产者接口Produce API生产者 API 用于将消息集发送到效劳器。为了提高效率，它允许在单个恳求中发送多个不同主题的不同分区的消息。生产者 API 使用通用

30、的消息集格式，但由于发送时还没有被安排偏移量，因此可以任意填写该值。生产消息恳求Produce Request1.2. ProduceRequest = RequiredAcks Timeout TopicName Partition MessageSetSize MessageSet3.4.5. RequiredAcks = int16 6.7.8. Timeout = int32 9.10.11.Partition = int32 12.13.14.MessageSetSize = int32 15.域FIELD描述这个值表示效劳端收到多少确认后才发送反响消息给客户RequiredAcks

31、端。假设设置为 0，那么效劳端将不发送反响消息这是唯一的效劳端不发送反响消息的状况。假设这个值为 1，那么效劳器将等到数据写入到本地日之后发送反响消息。假设这个TimeoutTopicName Partition值是-1，那么效劳端将堵塞，知道这个消息被全部的同步副本写入后再反响响应消息。对于其他大于 1 的值，效劳端将会堵塞，直到收到这个数量的写入反响后再反响响应消息但效劳器不会等大于同步中副本的数量，即到达同步中复本个数后，会停顿等待，即使所填的值大于这个副本个数。这个值供给了以毫秒为单位的超时时间，效劳器可以在这个时间内可以等待接收所需的Ack 确认的数目。超时并非一个精准的限制，有以下

32、缘由： 1不包括网络延迟， 2计时器开头在这一恳求的处理开头，所以假设有很多恳求，由于效劳器负载而导致的排队等待时间将不被包括在内， 3假设本地写入时间超过超时，我们将不会终止本地写操作，这样这个超时时间就不会得到遵守。要使硬超时时间，客户端应当使用套接字超时。该数据将会公布到的主题名称该数据将会公布到的分区MessageSetSize 后续消息集的长度，字节为单位MessageSet上面描述的标准格式的消息集合生产消息响应Produce Response1.2. ProduceResponse = TopicName Partition ErrorCode Offset3.4.5. Topi

33、cName = string 6.7.8. Partition = int32 9.10.11.ErrorCode = int16 12.13.14.Offset = int64 15.域描述Topic此响应对应的主题。Partition 此响应对应的分区。假设有，此分区对应的错误信息。错误以分区为单位供给，由于可ErrorCode 能存在给定的分区不行用或者被其他的主机维护非 Leader，但是其他的分区的恳求操作成功的状况Offset追加到该分区的消息集中的安排给第一个消息的偏移量。可能的错误码Possible Error Codes:(未完待续 TODO) 猎取消息接口Fetch API

34、猎取消息接口用于猎取一些主题分区的一个或多个的日志块。规律上依据指定主题，分区和消息起始偏移量开头猎取一批消息。在一般状况下，返回消息的偏移量将大于或等于开头偏移量。然而，假设是压缩消息，有可能返回的消息的偏移量比起始偏移量小。这类的消息的数量通常较少，并且调用者必需负责过滤掉这些消息。猎取数据指令恳求遵循一个长轮询模型，假设没有足够数量的消息可用，它们可以堵塞一段时间。作为优化，效劳器被允许在消息集的末尾返回局部消息。客户应处理这种状况。有一点要留意的是，猎取消息 API 需要指定消费的分区。现在的问题是如何让消费者知道消费哪个分区？特别地，作为一组消费者， 如何使得每个消费者猎取分区的一个

35、子集，并且平衡这些分区。我们 使用 zookeeper 动态地为 Scala 和 Java 客户端完成这个任务。这种方法的缺点是， 它需要一个相当胖的客户端并且需要客户端与zookeeper 联系。我们尚未创立一个Kafka 接口API，允许该功能被移动到在效劳器端并被更便利地访问。一个简洁的消费者的客户端 可以通过配置指定访问的分区，但这样将不能在某些消费者失效后做 到分区的动态重安排。我们期望能在下一个主要版本解决这一空白。数据猎取恳求Fetch Request1.2. FetchRequest=ReplicaIdMaxWaitTimeMinBytes TopicName Partitio

36、n FetchOffset MaxBytes3.4.5. ReplicaId = int32 6.7.8. MaxWaitTime = int32 9.10.11.MinBytes = int32 12.13.14.TopicName = string 15.16.17.Partition = int32 18.19.20.FetchOffset = int64 21.22.23.24.MaxBytes = int32域描述副本 ID 的是发起这个恳求的副本节点 ID。一般消费者客户端应ReplicaId该始终将其指定为-1，由于他们没有节点 ID。其他 broker 设置他们自己的节点 ID

37、。基于调试目的，以非代理身份模拟副本broker 发出猎取数据指令恳求时，这个值填-2。MaxWaitTime 假设没有足够的数据可发送时，最大堵塞等待时间，以毫秒为单位。返回响应消息的最小字节数目，必需设置。假设客户端将此值设为 0，效劳器将会马上返回，但假设没有的数据，效劳端会返回一个空消息集。假设它被设置为 1，则效劳器将在至少一个分区收到一个字节的数据的状况下马上返回，或者等到超时时间达MinBytes到。通过设置较高的值，结合超时设置，消费者可以在牺牲一点实时性能的状况下通过一次读取较大的字节的数据块从而提高的吞吐量例如，设置 MaxWaitTime 至 100 毫秒，设置MinBy

38、tes 为64K，将允许效劳器累积数据到达 64K 前等待长达 100ms 再响应。TopicName 主题topic名称Partition 猎取数据的 Partition id FetchOffset 猎取数据的起始偏移量MaxBytes此分区返回消息集所能包含的最大字节数。这有助于限制响应消息的大小。猎取消息响应Fetch Response1.2. FetchResponse=TopicNamePartitionErrorCode HighwaterMarkOffset MessageSetSize MessageSet3.4.5. TopicName = string 6.7.8. Pa

39、rtition = int32 9.10.11.ErrorCode = int16 12.13.14.HighwaterMarkOffset = int64 15.16.17.MessageSetSize = int3218.域 TopicName Partition描述返回消息所对应的主题Topic名称。返回消息所对应的分区 id。HighwaterMarkOffset 此分区日志中最末尾的偏移量。此信息可被客户端用来确定后面还有多少条消息。MessageSetSize MessageSet此分区中消息集的字节长度此分区猎取到的消息集，格式与之前描述一样可能的错误码Possible Erro

40、r Codes OFFSET_OUT_OF_RANGE (1) UNKNOWN_TOPIC_OR_PARTITION (3) NOT_LEADER_FOR_PARTITION (6) REPLICA_NOT_AVAILABLE (9) UNKNOWN (-1)偏移量接口又称 ListOffsetOffset API此 API 描述了一个主题分区的偏移量有效范围。生产者和猎取数据 API 的恳求必需发送到分区 Leader 所在的 broker 上，这需要通过使用元数据的 API 来确定。响应包含分区的起始偏移量以及“日志末端偏移量”，即，将被追加到给定分区中的下一个消息的偏移量。我们也觉得这个

41、 API 是略微有点时髦。偏移量恳求Offset Request1.2. OffsetRequest = ReplicaId TopicName Partition Time MaxNumberOfOffsets3.4.5. ReplicaId = int32 6.7.8. TopicName = string 9.10.11.Partition = int32 12.13.14.Time = int64 15.16.17.MaxNumberOfOffsets = int3218.域描述用来恳求确定时间(毫秒)前的全部消息。这里有两个特别取值： -1 表示Time 猎取最终一个 offset也

42、就是后面马上到来消息的 offset 值； -2 表示猎取最早的有效偏移量。留意，由于猎取到偏移值都是降序排序，因此恳求最早 Offset 的恳求将总是返回一个值偏移量响应Offset Response1.2. OffsetResponse = TopicName PartitionOffsets 3.4.5. PartitionOffsets = Partition ErrorCode Offset 6.7.8. Partition = int32 9.10.11.ErrorCode = int16 12.13.14.Offset = int64 15.可能的错误吗Possible Erro

43、r CodesoUNKNOWN_TOPIC_OR_PARTITION (3) NOT_LEADER_FOR_PARTITION (6) UNKNOWN (-1)偏移量提交/猎取接口Offset Commit/Fetch API这些 API 使得偏移量的能够集中治理。了解更多偏移量治理。依据 Kafka-993 的评论，直到 Kafka 0.8.1.1，这些 API 调用无法完全正常使用，他们这将在 0.8.2 版本中供给。消费者组协调员恳求Group Coordinator Request消费者组 Consumer Group 偏移量信息， 由一个特定的broker 维护，这个broker 称为消费者组协调员。即消费者需要向从这个特定的 broker 提交和猎取偏移量。可以通过发出一组协调员觉察恳求从而获得当前协调员信息。1.2. GroupCoordinatorRequest = GroupId 3.4.5. GroupId = s