¡Conozca los detalles de cómo trabajan los productores y consumidores de Kafka!
Cada partición es una secuencia ordenada (por lo que cada partición está ordenada internamente) e inmutable de registros. Estos registros se agregan continuamente a una confirmación estructurada. registro. A cada registro de una partición se le asigna un número de identificación secuencial llamado desplazamiento, que identifica de forma única cada registro de la partición.
Los únicos metadatos que se conservan para cada usuario son el desplazamiento o la posición del usuario en el registro. Este desplazamiento lo controla el usuario: normalmente el usuario avanza su desplazamiento linealmente a medida que lee los registros, pero en la práctica, dado que la posición la controla el usuario, el usuario puede utilizar los registros en el orden que desee. Por ejemplo, los usuarios pueden restablecer un desplazamiento anterior para reprocesar datos pasados, o saltar al registro más reciente y comenzar a usarlo "inmediatamente". (Los datos se procesan en secuencia de manera similar a un puntero de cursor, y el puntero se puede mover a voluntad).
Estructura de diseño de partición
La estrategia de partición del productor determina cómo el productor enviará el mensaje Existen principalmente los siguientes tipos de algoritmos para determinar qué partición usar:
La clasificación de mensajes de Kafka se logra utilizando la estrategia de almacenamiento de claves de la clave del mensaje. Un tema, una partición (división), un consumidor, consumo interno de un solo subproceso, escritura en N colas de memoria y luego N subprocesos consumen cada uno una cola de memoria.
Hay dos lugares donde Kafka comprime los mensajes enviados: la compresión del lado del productor y la compresión del lado del corredor.
Compresión del lado del productor La compresión del productor generalmente utiliza el algoritmo GZIP, de modo que cada conjunto de mensajes generado después de que se inicia el productor será comprimido por GZIP, ahorrando así ancho de banda de la red y espacio en disco en el lado de Kafka Broker. Parámetros de configuración:
Compresión del Broker En la mayoría de los casos, el Broker solo guardará el mensaje tal como está cuando se recibe del Productor sin modificarlo, pero las siguientes situaciones activarán la compresión del Broker
Descompresión del Consumidor Kafka encapsulará qué algoritmos de compresión están habilitados en una colección de mensajes y los descomprimirá en el Consumidor para realizar la operación de descompresión.
Kafka proporciona las siguientes funciones para garantizar que los mensajes no se pierdan, garantizando así la confiabilidad del mensaje.
Mecanismo de confirmación del productor cuando hay varios Kafka Brokers (según la política de configuración, uno o todos) reciben exitosamente un mensaje y lo escriben en el archivo de registro, le dicen al programa productor que el mensaje se envió exitosamente. Mensaje enviado exitosamente. En este punto, el mensaje se convierte oficialmente en un mensaje "comprometido" a los ojos de Kafka. acks es un parámetro del productor que representa su definición de mensaje "confirmado". Si se establece en todos, todos los agentes de replicación deben recibir el mensaje para considerarse "comprometidos". Esta es la definición de sumisión del más alto nivel.
Mecanismo de devolución de llamada de falla del productor. Los productores deben usar productor.send(msg) en lugar de productor.send(msg, callback). Recuerde utilizar siempre el método de envío con una notificación de devolución de llamada. productor.send(msg, callback) funciona de forma asincrónica y llama al método de devolución de llamada en caso de falla.
El mecanismo de reintento fallido establece el número de reintentos en un valor mayor. Aquí, el reintento también es un parámetro del productor, correspondiente al reintento automático del productor mencionado anteriormente. Cuando se produce una fluctuación transitoria de la red, es posible que no se puedan enviar mensajes y un productor configurado con un recuento de reintentos de 0 puede reintentar automáticamente el envío de mensajes para evitar la pérdida de mensajes.
El reconocimiento del consumidor garantiza que el mensaje se haya consumido antes de confirmarse.
Hay un parámetro enable.auto.commit en el lado del consumidor, es mejor configurarlo en falso y confirmar el desplazamiento manualmente. Como se mencionó anteriormente, esto es fundamental para escenarios de subprocesos múltiples de un solo consumidor.
Mecanismo de replicación Establezca replication.factor >= 3. Este también es un parámetro del lado del Broker. De hecho, la idea aquí es que es mejor conservar más copias de los mensajes; después de todo, el principal mecanismo para evitar la pérdida de mensajes en la actualidad es la redundancia. establecer min.insync.replicas gt;1. Este sigue siendo un parámetro del lado del corredor que controla en cuántas copias se debe escribir un mensaje antes de que se considere "confirmado". Configurarlo como mayor que 1 mejora la durabilidad del mensaje. En un entorno real, nunca utilice el valor predeterminado de 1. Asegúrese de replication.factor > min.insync.replicas. Si son iguales, si una copia se bloquea, toda la partición no funcionará. No sólo queremos mejorar la durabilidad de los mensajes y evitar la pérdida de datos, sino que también queremos hacerlo sin reducir la disponibilidad. La configuración recomendada es replication.factor = min.insync.replicas 1.
El mecanismo utilizado para limitar la selección de líderes por parte del corredor Establezca unclean.leader.election.enable = false. Este es un parámetro del lado del Broker que se utiliza para controlar qué Brokers son elegibles para ejecutarse como líder de la partición. Si un Broker va demasiado por detrás del líder original, inevitablemente perderá mensajes una vez que se convierta en el nuevo líder. Por lo tanto, este parámetro se suele establecer en falso para que no se produzca esta situación.
Debido a la existencia del mecanismo de confirmación del productor de Kafka y el mecanismo de reintento fallido, los mensajes de Kafka no se perderán, pero debido a retrasos en la red y otras razones, pueden ocurrir envíos repetidos. Por tanto, debemos considerar el diseño de idempotencia del mensaje. Kafka proporciona el método Productor de idempotencia para garantizar la idempotencia de los mensajes. Utilice **** para activar la idempotencia.
Alcance del productor de idempotencia:
Los productores transaccionales de Kafka Transactions garantizan que los mensajes se escriban de forma atómica en múltiples particiones. O todos los mensajes se escriben correctamente o todos los mensajes no se escriben. Además, los productores transaccionales son inmunes a los reinicios de procesos. Cuando regresan de un reinicio, Kafka se asegura de que los mensajes que envían se procesen solo una vez. Las transacciones se abren de la misma forma.
Los grupos de consumidores son un mecanismo de consumidores escalable y tolerante a fallas proporcionado por Kafka. Está formado por uno o más consumidores que comparten el mismo ID de grupo. Todos los consumidores del grupo coordinan el consumo de todas las particiones del tema suscrito. Por supuesto, cada partición solo puede ser utilizada por un consumidor del mismo grupo de consumidores.
Un grupo de consumidores tiene las siguientes características:
Posición del consumidor Posición del consumidor, o desplazamiento. Los consumidores necesitan realizar un seguimiento de la cantidad de datos que consumen durante su recorrido de consumo. Envío de desplazamiento Hay dos formas de envío de desplazamiento: automático y manual.
Kafka gestiona las compensaciones de los consumidores a través del tema integrado (__consumer_offsets).
El reequilibrio es esencialmente un protocolo que estipula cómo todos los consumidores del grupo de consumidores acuerdan distribuir cada partición del tema suscrito.
Kafka proporciona un rol: coordinador para realizar la gestión de los grupos de consumidores.
El coordinador de grupo es un servicio que cada Broker inicia cuando se inicia. Se utiliza para almacenar la metainformación del grupo y registrar la información de compensación de la partición correspondiente en el tema integrado de Kafka (___ consumer_offsets).
El proceso de reequilibrio se divide en dos pasos: Unirse y Sincronizar. Unirse, como su nombre indica, significa unirse a un grupo. En este paso, todos los miembros envían una solicitud JoinGroup al coordinador para unirse al grupo de consumidores. Una vez que todos los miembros hayan enviado una solicitud JoinGroup, el coordinador seleccionará un consumidor para que actúe como líder del grupo y enviará la información de membresía y suscripción del grupo al líder del grupo; tenga en cuenta que el líder del grupo y el coordinador no son el mismo concepto. El líder es responsable de consumir el plan de distribución.
Sincronización, este es el paso donde el líder comienza a asignar planes de consumo, es decir, qué consumidores son responsables de consumir qué partes de qué temas. Una vez completada la asignación, el líder encapsula el plan en una solicitud de SyncGroup al coordinador. Los no líderes también envían solicitudes de SyncGroup, y solo los no líderes envían solicitudes de SyncGroup. Después de que el coordinador recibe el plan de asignación, lo envía a cada consumidor en una respuesta de SyncGroup para que todos los miembros del grupo sepan qué particiones deben usar.