Directorio de artículos
Conceptos importantes
corredor
Un intermediario es una instancia de Kafka, responsable de recibir, reenviar y almacenar mensajes Un clúster de Kafka se compone de varios intermediarios.
tema
El tema de Kafka es un concepto lógico, es decir, agrupar y categorizar mensajes para facilitar el procesamiento de diferentes mensajes de lógica empresarial. El concepto de índice en topic y Elasticsearch es similar.
dividir
La partición de kafka es un concepto físico, que corresponde a una carpeta en el sistema de archivos. La partición es para el tema. Es principalmente para considerar la gran cantidad de datos del tema. Se puede procesar en paralelo dividiendo los datos del tema en particiones. , Mejora la cantidad de simultaneidad.
La partición en kafka es similar al fragmento en Elasticsearch, y ambos dividen físicamente los datos de la clasificación lógica unificada.
segmento
La partición de kafka corresponde a una carpeta. Después de pensarlo un poco, encontrará que el almacenamiento de mensajes debe ser un archivo. Entonces, ¿cuál es el nombre del archivo donde Kafka almacena el mensaje?
La respuesta es segmento, que se traduce en segmentos en muchos lugares.
El segmento es una división física adicional del tema de Kafka Al configurar el tamaño del segmento de manera razonable de acuerdo con la situación real de la máquina y cooperar con el propio mecanismo de indexación de Kafka, las operaciones de lectura y escritura se pueden realizar más rápidamente.
compensar
offset es el offset del mensaje, este offset es el número de mensajes, no bytes
réplica
La réplica es una copia, básicamente todo el middleware distribuido tiene el concepto de copia
La copia de Kafka es para partición, no para tema.
En el clúster de Kafka, la disponibilidad se mejora mediante la distribución de diferentes copias de la partición en diferentes intermediarios.Cuando un intermediario está inactivo, hay otras copias disponibles.
La copia tiene dos atributos importantes: LEO y HW
Log End Offset (LEO): el desplazamiento del siguiente mensaje en el registro
High Watermark (HW): el LEO más pequeño de todas las copias
¿Por qué el LEO más pequeño entre todas las copias se llama la marca de agua más alta (HW)?
Principalmente porque Kafka no permite que los consumidores consuman más que el mensaje LEO más pequeño en todas las réplicas, por lo que se llama marca de agua alta (HW)
Esto se debe principalmente a las inconsistencias de los datos. Por ejemplo, el LEO en el líder es relativamente grande y luego se cuelga y otras copias se convierten en el líder.
productor
Productor de mensajes, un servicio que publica mensajes en el clúster de Kafka
consumidor
Consumidor de mensajes, un servicio que consume mensajes del clúster de Kafka
Grupo de consumidores
El grupo de consumidores es un concepto de la API de consumidores de alto nivel. Cada consumidor pertenece a un grupo de consumidores y cada mensaje solo puede ser consumido por un consumidor del grupo de consumidores, pero puede ser consumido por varios grupos de consumidores.
Al configurar el grupo de consumidores, un mensaje puede ser consumido por diferentes grupos, lo cual es muy práctico. Por ejemplo, un mensaje de inicio de sesión puede ser necesario tanto para el negocio de estadísticas de datos como para la actividad empresarial. Luego, solo necesita configurar diferentes grupos de consumidores para consumir el mismo inicio de sesión. Noticias.
líder 与 seguidor
La copia tiene 2 roles, uno es líder y el otro es seguidor.
Solo hay un líder en la misma copia y las otras copias son seguidores.
El productor y el consumidor solo interactúan con el líder, y luego el líder y el seguidor interactúan.
Por ejemplo, el productor envía un mensaje al líder, y el líder reenvía el mensaje al seguidor, y ejecutará diferentes respuestas según la configuración de ack del productor, que se describirá en detalle más adelante.
controlador
El controlador es para el corredor. Los corredores en el grupo de Kafka elegirán un líder para controlar la elección del líder de la partición, la conmutación por error y otras operaciones. El líder elegido por el corredor es el controlador.
La elección de los intermediarios depende de Zookeeper. Los nodos de intermediarios van a Zookeeper para registrar un nodo temporal. Debido a que solo un intermediario se registrará correctamente, los demás fallarán. El intermediario que registró correctamente el nodo temporal en Zookeeper se convertirá en el controlador y los otros intermediarios se denominarán seguidor de intermediario. .
El controlador monitoreará toda la información de otros corredores. Si el controlador se cae, el nodo temporal en zookeeper desaparecerá. En este momento, todos los corredores irán a Zookeeper para registrar un nodo temporal juntos, porque solo un corredor se registrará correctamente Todo lo demás fallará, por lo que el Broker que registró con éxito el nodo temporal en Zookeeper se convertirá en el nuevo controlador.
Una vez que un corredor deja de funcionar, el controlador leerá el estado de todas las particiones en el corredor inactivo en zookeeper y seleccionará una réplica en la lista ISR como líder de partición.
Si todas las réplicas de la lista de ISR están inactivas, elija una réplica superviviente como líder;
si todas las réplicas de la partición están inactivas, establezca el nuevo líder en -1, espere la recuperación y espere a que se recupere cualquier réplica del ISR Y elíjalo como líder, o elige la primera réplica que sobreviva, no necesariamente el líder en el ISR.
Cuando el intermediario no funciona, el controlador también notificará al cuidador del zoológico y el cuidador del zoológico notificará a otros intermediarios.
Problema de cerebro dividido del corredor: después de que el
controlador se haya registrado con éxito en Zookeeper, el valor predeterminado del tiempo de espera para la comunicación con Zookeeper es 6 s, es decir, si el controlador no tiene un latido con Zookeeper en 6 s, entonces Zookeeper piensa que el controlador está muerto.
Este nodo temporal se eliminará en Zookeeper, luego otros corredores pensarán que el controlador se ha ido y se apresurarán a registrar el nodo temporal nuevamente, y el corredor registrado con éxito se convertirá en el controlador.
Entonces, el controlador anterior necesita varias paradas para apagar la supervisión de varios nodos y eventos. Pero cuando el tráfico de lectura y escritura de Kafka es muy grande, el mensaje que llega del productor en este momento no puede aterrizar debido a la presencia de dos controladores en el clúster de Kafka, lo que resulta en la acumulación de datos.
coordinador
El coordinador de grupo es un servicio y cada corredor iniciará un servicio cuando comience.
La función del Coordinador de Grupo es almacenar la Metainformación relacionada del Grupo y registrar la información de Offset de la Partición correspondiente en el tema __consumer_offsets de Kafka.
Antes de 0.9, Kafka se basaba en Zookeeper para almacenar la información de compensación de Partición (consumidores / {grupo} / compensaciones / {tema} / {partición}), porque ZK no es adecuado para operaciones de escritura frecuentes, así que después de 0.9, a través del tema integrado Manera de registrar el Offset de la Partición correspondiente.
Configuración importante de Kafka
relacionado con boker
#在集群中的唯一标识broker，非负数
broker.id=1
#broker server服务端口
port=9091
#kafka数据的存放地址，多个地址的话用逗号分割D:\\data11，D:\\data12
log.dirs=D:\\kafkas\\datas\\data1
#ZK集群的地址，可以是多个，多个之间用逗号分割hostname1:port1,hostname2:port2
zookeeper.connect=localhost:2181
#ZK连接超时时间
zookeeper.connection.timeout.ms=6000
#ZK会话超时时间
zookeeper.session.timeout.ms=6000
#segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
#segment的大小，达到指定大小会新创建一个segment文件，会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
# broker接受的消息体的最大大小
message.max.bytes = 1000012
#broker处理消息的最大线程数
num.network.threads=3
#broker处理磁盘IO的线程数
num.io.threads=8
#socket的发送缓冲区
socket.send.buffer.bytes=102400
#socket的接受缓冲区
socket.receive.buffer.bytes=102400
#socket请求的最大数值，message.max.bytes必然要小于socket.request.max.bytes
socket.request.max.bytes=104857600
#topic默认分区个数，会被topic创建时的指定参数覆盖
num.partitions=1
#partition副本数量配置，默认1，表示没有副本，2表示除了leader还有一个follower
default.replication.factor =1
#是否允许自动创建topic，若是false，就需要手动创建topic
auto.create.topics.enable =true
productor (relacionado con el productor)
# 0不管消息是否写入成功，1只需要leader写入消息成功，all需要leader和ISR中的follower都写入成功
acks = 1
#设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。
#如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候，send()方法调用要么被阻塞，要么抛出异常
buffer.memory = 10240
# 当buffer.memory不足，阻塞多久抛出异常
max.block.ms = 3000
# 默认消息发送时不会被压缩。可设置为snappy、gzip、lz4
compression.type = snappy
# 重试次数
retries = 0
# 重试时间间隔
retry.backoff.ms = 100
# 发向相同partition每个批次的大小,默认16384
batch.size = 10240
# batch.size要产生消息比发送消息快才会出现
# linger.ms可以控制让发送等n毫秒再发送，以达到批量发送的目的
linger.ms = 0
# 控制生产者每次发送的请求大小，默认1M
max.request.size = 1048576
# 指定了生产者在收到服务器响应之前可以发送多少个消息
max.in.flight.requests.per.connection = 1
# tcp缓冲区大小
receive.buffer.bytes = 4096
send.buffer.bytes = 4096
El algoritmo de compresión ágil ocupa menos CPU, tiene un mejor rendimiento y relación de compresión El
algoritmo de compresión gzip ocupa más CPU, pero proporcionará una relación de compresión más alta.
max.in.flight.requests.per.connection causa problemas de secuencia de mensajes. Si: reintentos> 0 && max.in.flight.requests.per.connection> 1:
entonces, si el primer lote de mensajes no se puede escribir, y Si el segundo lote se escribe correctamente, volverá a intentar escribir el primer lote. Si el primer lote también se escribe correctamente en este momento, el orden de los dos lotes se invierte.
max.in.flight.requests.per.connection = 1, incluso si se produce un reintento, se puede garantizar que el mensaje se escribe en el orden en que se envió.
consumidor (relacionado con el consumidor)
# broker服务器列表
bootstrap.servers=localhost:9092,localhost:9093,localhost:9094
# 消费者每次poll数据时的最大数量
max.poll.records = 500
# 为true则自动提交偏移量
enable.auto.commit = true
# 自动提交偏移量周期(时间间隔)
auto.commit.interval.ms = 5000
# 如果该配置时间内consumer没有响应Coordinator的心跳检测，就认为consumer挂了，rebalance
session.timeout.ms = 10000
# Coordinator的心跳检测周期
heartbeat.interval.ms = 2000
# 当没有初始偏移量时，怎么办，默认latest
# earliest: 自动重置为最早的offset
# latest: 自动重置为最后的offset
# none: 如果在消费者组中没有前置的offset，抛异常
auto.offset.reset=latest
# 一次最小拉取多少字节，默认1字节
fetch.min.bytes=1
# 一次最多拉取多少字节数据，默认50M
fetch.max.bytes=52428800
# 一次拉取最多等待多少毫秒，默认500
fetch.max.wait.ms=500
réplica (relacionada con la réplica)
#leader等待follower的最常时间，超过就將follower移除ISR(in-sync replicas)
replica.lag.time.max.ms =10000
#follower最大落后leader多少条消息，把此replicas迁移到其他follower中，在broker数量较少,或者网络不足的环境中,建议提高此值
replica.lag.max.messages =4000
#follower与leader之间的socket超时时间
replica.socket.timeout.ms=30*1000
#leader复制时候的socket缓存大小
replica.socket.receive.buffer.bytes=64*1024
#replicas每次获取数据的最大大小
replica.fetch.max.bytes =1024*1024
#replicas同leader之间通信的最大等待时间，失败了会重试
replica.fetch.wait.max.ms =500
#fetch的最小数据尺寸,如果leader中尚未同步的数据小于该值,将会阻塞,直到满足条件
replica.fetch.min.bytes =1
#leader进行复制的线程数，增大这个数值会增加follower的IO
num.replica.fetchers=1
log (relacionado con el registro)
#segment文件大小，会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
#segment滚动时间，没有达到log.segment.bytes也会强制新建一个segment，topic参数覆盖
log.roll.hours =24*7
#日志清理策略选择有：delete和compact主要针对过期数据的处理
log.cleanup.policy = delete
#数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据
log.retention.minutes=6000
#topic每个分区大小，一个topic的大小限制=分区数*log.retention.bytes，-1没有大小
log.retention.bytes=-1
#文件大小检查的周期时间
log.retention.check.interval.ms=50000
#是否开启日志清理，默认true
log.cleaner.enable=true
#日志清理的线程数
log.cleaner.threads = 2
#日志清理时候处理的最大大小
log.cleaner.io.max.bytes.per.second=None
#日志清理去重时候的缓存空间，在空间允许的情况下，越大越好
log.cleaner.dedupe.buffer.size=500*1024*1024
#日志清理时候用到的IO块大小一般不需要修改
log.cleaner.io.buffer.size=512*1024
#值越大一次清理越多，hash冲突也越严重
log.cleaner.io.buffer.load.factor=0.9
#检查是否有需要清理的日志间隔
log.cleaner.backoff.ms =15000
#日志清理的频率控制，越大意味着更高效的清理，同时会存在一些空间上的浪费，topic参数覆盖
log.cleaner.min.cleanable.ratio=0.5
#对于压缩的日志保留的最长时间，会被topic创建时的指定参数覆盖
log.cleaner.delete.retention.ms =100000
#对于segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
#索引的offset间隔，设置越大，扫描速度越快，但是也更吃内存
log.index.interval.bytes =4096
#多少条消息，执行一次刷新到磁盘操作
log.flush.interval.messages=9223372036854775807
#多少毫秒之后刷新到磁盘一次，没有设置使用log.flush.scheduler.interval.ms
log.flush.interval.ms = null
#检查是否需要刷新到磁盘的时间间隔
log.flush.scheduler.interval.ms =3000
#文件在索引中清除后保留的时间一般不需要去修改
log.delete.delay.ms =60000
#控制上次落盘的时间点，以便于数据恢复
log.flush.offset.checkpoint.interval.ms =60000
El parámetro log.cleanup.policy controla el registro claramente, el valor predeterminado es eliminar, puede configurar el parámetro log.cleanup.policy en "eliminar, compactar"
El compacto aquí no es comprimir, sino integrar la clave de cada mensaje, para valores diferentes con la misma clave, solo se mantiene la última versión.
Preste atención a la diferencia entre compacto y compresión. Compacto es más como marcar y clasificar la recuperación de memoria. Compresión significa compresión. La compresión en kafka es para el contenido del mensaje.
La eliminación de Kafka puede basarse en 3:
- Basado en el tiempo
- Según el tamaño
- Basado en compensación
Log.retention.hours, log.retention.minutes y log.retention.ms están configurados, y la
configuración basada en tiempo tiene prioridad de mayor a menor :
- log.retention.ms
- log.retention.minutes
- log.retention.hours
De forma predeterminada, solo se configura el parámetro log.retention.hours y su valor es 168. Por lo tanto, el tiempo de retención del archivo de segmento de registro es de 7 días de forma predeterminada.
La eliminación basada en el tamaño está controlada por el parámetro log.retention.bytes, el valor predeterminado es -1 y no hay límite de tamaño.
Si alguno de log.retention.bytes y log.retention.minutes cumple con los requisitos, se eliminará y se sobrescribirá con los parámetros especificados cuando se cree el tema.
Kafka fusionará los segmentos cada vez después de limpiar el registro. Después de la fusión, el tamaño no superará la configuración de log.segments.bytes y el valor predeterminado es 1GB.
controlador
#是否允许关闭broker,若是设置为true,会关闭所有在broker上的leader，并转移到其他broker
controlled.shutdown.enable=false
#控制器关闭的尝试次数
controlled.shutdown.max.retries=3
#每次关闭尝试的时间间隔
controlled.shutdown.retry.backoff.ms=5000
#partition leader与replicas之间通讯时,socket的超时时间
controller.socket.timeout.ms =30000
#partition leader与replicas数据同步时,消息的队列尺寸
controller.message.queue.size=10
controlado.shutdown.enable = true es principalmente para un cierre ordenado:
- Puede acelerar el reinicio
- Deje que el líder cambie más rápido y reduzca la indisponibilidad de cada partición a unos pocos milisegundos
para resumir
