8 imágenes te llevan a comprender completamente el mecanismo central de kafka

prefacio

Kafka es un producto de cola de mensajes que se usa comúnmente en las empresas en la actualidad y se puede usar para la reducción de picos, el desacoplamiento y la comunicación asíncrona. Especialmente en el campo de big data, es ampliamente utilizado, principalmente debido a su alto rendimiento y baja latencia, y también se utiliza en las soluciones de nuestra empresa. Dado que kafka es tan importante en la empresa, este artículo le brindará una comprensión integral de kafka a través de algunas imágenes. Ahora también podríamos tomar la perspectiva de los diseñadores de kafka para pensar sobre cómo diseñar, cuál es su arquitectura y qué componentes hay Composición, cómo expandir, etc.

infraestructura kafka

Ahora bien, si hay 100T de mensajes para enviar a Kafka, la cantidad de datos es demasiado grande para almacenarse en una sola máquina. Ante esta situación, ¿cómo se debe diseñar?

Es muy simple, divide y vencerás, si uno no es suficiente, entonces hay más, lo que forma un grupo kafka. Como se muestra en la figura a continuación, un corredor es un nodo de Kafka, y tres nodos comparten 100T de datos, cada nodo tiene aproximadamente 33T, lo que puede resolver el problema y mejorar el rendimiento.

1. Tema: Puede entenderse como una cola, en un clúster de Kafka se pueden definir muchos temas, como el de la figura anterior topicA.
2. Partición: para lograr la escalabilidad y mejorar el rendimiento, topicse puede a múltiples broker(es decir, servidores), se topicpuede dividir en múltiples partition, cada una partitiones una cola ordenada. Por ejemplo, topicA en la figura anterior se divide en tres partition.
3. Réplica: si los datos solo se colocan brokeren una copia, ¿ brokerqué debemos hacer si esta se cae? Para lograr una alta disponibilidad, cada partición topicde tiene varias copias, una Leadery varias Follower. Por ejemplo, la línea punteada en la figura anterior conecta su copia.
4. Líder: el "principal" de varias copias de cada partición, el objeto al que el productor envía datos y el objeto al que el consumidor consume datos Leader.
5. Seguidor: el "esclavo" en múltiples copias de cada partición, sincroniza los datos Leaderen y Leaderlos mantiene sincronizados con los datos. LeaderCuando ocurre una falla, Followeruno se convierte en el nuevo Leader.
6. Productor: El productor de mensajes es el cliente al que Kafka brokerenvía mensajes , lo cual se explicará en detalle más adelante.
7. Consumidor : Consumidor de mensajes, el cliente que Kafka brokerobtiene mensajes, varios Consumerformarán un grupo de consumidores, que se explicará en detalle más adelante.
8. Zookeeper : se usa para registrar algunos metadatos en Kafka, como el intermediario en el clúster de Kafka, quién es el líder, etc., pero Kafkadespués de la versión 2.8.0, también admite métodos que no son ZK, lo que reduce en gran medida la interacción con ZK.

Proceso de producción de Kafka

La estructura general de kafka se explicó a través de una imagen anterior, así que ahora echemos un vistazo a todo el proceso de envío del productor de kafka, que también tiene muchos artículos.

En el proceso de envío de mensajes, están involucrados dos subprocesos: mainsubproceso e Sendersubproceso . Se crea un deque en mainel subproceso RecordAccumulator. mainLos subprocesos envían mensajes a RecordAccumulator, y Senderlos subprocesos obtienen RecordAccumulatory Kafka Broker.

1. En el subproceso principal, el mensaje kafkaProduceres creado , y luego almacenado en el acumulador de mensajes ( RecordAccumulator, también conocido como recopilador de mensajes) después de pasar por posibles interceptores, serializadores y particionadores.

• 拦截器： 可以用来在消息发送前做一些准备工作，比如按照某个规则过滤不符合要求的消息、修改消息的内容等，也可以用来在发送回调逻辑前做一些定制化的需求，比如统计类工作。
• 序列化器： 用于在网络传输中将数据序列化为字节流进行传输，保证数据不会丢失。
• 分区器： 用于按照一定的规则将数据分发到不同的kafka broker节点中

2. Sender 线程负责从 RecordAccumulator 获取消息并将其发送到 Kafka 中。

• RecordAccumulator 主要用来缓存消息以便 Sender 线程可以批量发送，进而减少网络传输的资源消耗以提升性能。

• RecordAccumulator 缓存的大小可以通过生产者客户端参数 buffer.memory 配置，默认值为 33554432B ，即 32M。

• 主线程中发送过来的消息都会被迫加到 RecordAccumulator 的某个双端队列（ Deque ）中，RecordAccumulator 内部为每个分区都维护了一个双端队列，即 Deque<ProducerBatch>, 消息写入缓存时，追加到双端队列的尾部。
• Sender 读取消息时，从双端队列的头部读取。ProducerBatch 是指一个消息批次；与此同时，会将较小的 ProducerBatch 凑成一个较大 ProducerBatch ，也可以减少网络请求的次数以提升整体的吞吐量。ProducerBatch 大小可以通过batch.size 控制，默认16kb。
• Sender 线程会在有数据积累到batch.size,默认16kb，或者如果数据迟迟未达到batch.size，Sender线程等待linger.ms设置的时间到了之后就会获取数据。linger.ms单位ms，默认值是0ms，表示没有延迟。

3. Sender 从 RecordAccumulator 获取缓存的消息之后，会将数据封装成网络请求<Node,Request> 的形式，这样就可以将 Request 请求发往各个 Node 了。
4. 请求在从 sender 线程发往 Kafka 之前还会保存到 InFlightRequests 中，它的主要作用是缓存了已经发出去但还没有收到服务端响应的请求。InFlightRequests默认每个分区下最多缓存5个请求，可以通过配置参数为max.in.flight.request.per. connection修改。
5. 请求Request通过通道Selector发送到kafka节点。
6. 发送后，需要等待kafka的应答机制，取决于配置项acks.

• 0：生产者发送过来的数据，不需要等待数据落盘就应答。
• 1：生产者发送过来的数据，Leader 收到数据后应答。
• -1（all）：生产者发送过来的数据，Leader和副本节点收齐数据后应答。默认值是-1，-1 和all 是等价的。

7. Request请求接受到kafka的响应结果，如果成功的话，从InFlightRequests 清除请求，否则的话需要进行重发操作，可以通过配置项retries决定，当消息发送出现错误的时候，系统会重发消息。retries表示重试次数。默认是 int 最大值，2147483647。
8. 清理消息累加器RecordAccumulator 中的数据。

kafka消费者流程

原来kafka生产者发送经过了这么多流程，我们现在来看看kafka消费者又是如何进行的呢？

Kafka 中的消费是基于拉取模式的。消息的消费一般有两种模式：推送模式和拉取模式。推模式是服务端主动将消息推送给消费者，而拉模式是消费者主动向服务端发起请求来拉取消息。

kafka是以消费者组进行消费的，一个消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的groupid相同。

• 消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费。如果向消费组中添加更多的消费者，超过主题分区数量，则有一部分消费者就会闲置，不会接收任何消息。
• 消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

那么问题来了，kafka是如何指定消费者组的每个消费者消费哪个分区？每次消费的数量是多少呢？

一、如何制定消费方案

1. 消费者consumerA，consumerB, consumerC向kafka集群中的协调器coordinator发送JoinGroup的请求。coordinator主要是用来辅助实现消费者组的初始化和分区的分配。

• coordinator老大节点选择 = groupid的hashcode值 % 50（ __consumer_offsets内置主题位移的分区数量）例如： groupid的hashcode值 为1，1% 50 = 1，那么__consumer_offsets 主题的1号分区，在哪个broker上，就选择这个节点的coordinator作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。

2. 选出一个 consumer作为消费中的leader，比如上图中的ConsumerB。
3. 消费者leader制定出消费方案，比如谁来消费哪个分区等
4. 把消费方案发给coordinator
5. 最后coordinator就把消费方 案下发给各个consumer, 图中只画了一条线，实际上是有下发各个consumer。

注意，每个消费者都会和coordinator保持心跳（默认3s），一旦超时（session.timeout.ms=45s），该消费者会被移除，并触发再平衡；或者消费者处理消息的时间过长（max.poll.interval.ms=5分钟），也会触发再平衡，也就是重新进行上面的流程。

二、消费者消费细节

现在已经初始化消费者组信息，知道哪个消费者消费哪个分区，接着我们来看看消费者细节。

1. 消费者创建一个网络连接客户端ConsumerNetworkClient, 发送消费请求，可以进行如下配置：

• fetch.min.bytes: 每批次最小抓取大小，默认1字节
• fetch.max.bytes: 每批次最大抓取大小，默认50M
• fetch.max.wait.ms：最大超时时间，默认500ms

2. 发送请求到kafka集群
3. 成功的回调，会将数据保存到completedFetches队列中
4. 消费者从队列中抓取数据，根据配置max.poll.records一次拉取数据返回消息的最大条数，默认500条。
5. 获取到数据后，需要经过反序列化器、拦截器等。

kafka的存储机制

我们都知道消息发送到kafka，最终是存储到磁盘中的，我们看下kafka是如何存储的。

一个topic分为多个partition，每个partition对应于一个log文件，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，每个partition分为多个segment。每个segment包括：“.index”文件、“.log”文件和.timeindex等文件，Producer生产的数据会被不断追加到该log文件末端。

上图中t1即为一个topic的名称，而“t1-0/t1-1”则表明这个目录是t1这个topic的哪个partition。

kafka中的索引文件以稀疏索引（sparseindex）的方式构造消息的索引，如下图所示：

1.根据目标offset定位segment文件

2.找到小于等于目标offset的最大offset对应的索引项

3.定位到log文件

4.向下遍历找到目标Record

注意：index为稀疏索引，大约每往log文件写入4kb数据，会往index文件写入一条索引。通过参数log.index.interval.bytes控制，默认4kb。

那kafka中磁盘文件保存多久呢？

kafka 中默认的日志保存时间为 7 天，可以通过调整如下参数修改保存时间。

• log.retention.hours，最低优先级小时，默认 7 天。
• log.retention.minutes，分钟。
• log.retention.ms，最高优先级毫秒。
• log.retention.check.interval.ms，负责设置检查周期，默认 5 分钟。

总结

其实kafka中的细节十分多，本文也只是对kafka的一些核心机制从理论层面做了一个总结，更多的细节还是需要自行去实践，去学习。

欢迎关注个人公众号【JAVA旭阳】交流学习