Kafka Protocal Guide

NetWork

Kafka使用二进制的TCP协议。 协议定义了所有的API包括：请求相应消息对。所有的消息使用字节大小来分界。

客户端(Consumer和Producer)和broker初始化socket链接,然后向broker中写入一串消息，然后从broker中读取相应的回应消息。链接和断开过程不需要握手。

使用TCP ,如果在多次请求时保持持久链接来补偿TCP握手的消耗,这样更好。

客户端将会和多个broker保持一个链接，因为数据被分区到多个broker中，客户端需要与拥有数据的broker保持链接。但是，一个客户端不需要和同一个broker建立多个链接。例如：长轮询。

broker确保在一个TCP链接上面，请求将会按照他们发送的顺序被处理,同时也会按照顺序被相应。broker请求处理运行每一个链接上面请求被顺序处理。

注意，客户端可以使用非阻塞IO来实现请求管道，从而实现高吞吐。 例如：客户端在等待之前的请求同时，依然可以发送请求，因为之前被输出的请求将会在操作系统的socket 缓冲区保存。

broker用一个请求的最大限制的配置，如果请求超过了配置的最大限制，那么socket将会被断开链接。

Partitioning and Bootstrapping

Kafka是一个分片的系统，所以所以的broker都没有完整的数据集合。所有的topic都被分割到预先定义的分区中。

所有拥有分区系统都有同样一个问题就是一条数据如何被分配到指定的分区中。在apache kafka中，producer直接控制着消息的分片，broker本身不会包含任何有关分片的语义，即broker本身不会包含一条消息如何分片到指定的broker中。在kafka 中，当发送消息时，producer直接分配消息到指定的分区中，在获取消息时，consumer直接从指定的分区中获取消息。如果想两个客户端使用相同的分区规则，那么他们必须使用相同的方法去计算映射到分区的关键值。

被发送到broker中或者从broker中获取的消息都必须是master. 在kafka中这个条件是强制的，如果一条消息被发送错误的broker中，那么客户端将会得到一个错误码。(NOTLeaderForPartition)

那么客户端如何找到topic是否存在，topic有哪些分区？ 以及broker有哪些分区？ 以及客户端如何直接找到正确的host和port呢？

这些信息都是动态变化的，所以你不能配置一个静态的配置文件。 在kakfa中，任何一个broker都可以回到集群中任何一个broker的元数据。这些元数据包括：有哪些topic，这些topic有哪些分区，哪一个broker是分区的master,以及这些broker的ip和地址信息。

换句话说，客户端可以向任何一broker来询问信息，broker也将会告诉客户端在集群中其他broker的存在，以及其他broker有什么分区等等。

第一个broker也行做不到，但是两三个broker就可以做到。所以，在kafka中，在客户端中仅仅配置两个或者三个broker的ip和端口，可以了。这也是最佳实践。

客户端不需要轮询broker来查看集群是否发生了改变。当初始化后建立缓存信息，当收到一个错误提示后，那么缓存就失效了，这样可以再次获取元数据。

错误可以来自两种形式：1、socket错误，表示客户端不能与指定的broker通信。2、一个错误码表示broker不在提供请求需要的数据。

整个过程如下：

1、轮询一个 kafka url自启动列表，知道我们和所有的broker建立链接，获取到集群的元数据

2、从合适的broker中处理生成、消费消息

3、如果我们收到一个socket错误或者错误码，我们将刷新元数据重新开始（1）

Paritioning  Strategies

在apache kafka中,producer 控制着消息发送到哪一个指定的broker中。也就是说，kafka会暴露一个函数给终端用户使用？

在kafka中分区主要有两个目的：

1、主要均衡数据和均衡broker请求的压力。

2、提供一个在分区中可以顺序处理，同时又可以分摊同一个topic压力。

为了完成简单的负载均衡，一个简单的方式就是通过客户端在所以的broker中进行轮询发送请求。另外一个选择，当produer的个数比broker数量多时，可以通过客户在所以broker中随机一个broker来发送请求。

语义分区意味着当把消息发送到分区时使用相同的KEY.例如：当处理一个单击消息时，可以通过user id来实现分区。这样，所以分区的所有消息只会有一个消费者。

为了完成语义分区，客户端可以使用消息管理的KEY,同时使用相同的哈希算法把消息分发到同一个broker的分区中。

Batching 

我们的API鼓励把多个小消息批量执行来提供消息。这是一个很重要方法来提供性能。kafka的api中，发送消息或者获取消息都允许一次批量请求，而不鼓励分批请求。

一个优秀的客户端可以充分利用批量的原则，同时，支持异步的方式。

客户端可以忽略这些，可以按照他们自己喜欢的方式，可以每次发送一个请求消息

原文链接：

https://kafka.apache.org/protocol.html#protocol_philosophy