Garantía de entrega de mensajes de Kafka: transacción e idempotencia

1. Introducción

Las garantías de entrega de mensajes son críticas para la confiabilidad de los sistemas distribuidos. La garantía de entrega de mensajes es uno de los temas centrales para garantizar la confiabilidad del sistema en sistemas distribuidos. El sistema debe garantizar que los mensajes se entreguen como se espera para satisfacer las necesidades comerciales.
Kafka es un sistema de cola de mensajes distribuidos. Como middleware de mensajes, a menudo se usa para implementar un servicio de entrega de mensajes basado en un modelo de publicación/suscripción. Por lo tanto, las garantías de entrega de mensajes deben proporcionarse en Kafka.

2. El problema de la entrega de mensajes

2.1 El problema de los mensajes duplicados

Consumo repetido

En Kafka, debido a problemas de red y otras razones, los mensajes pueden entregarse repetidamente a los consumidores, lo que genera el problema del consumo repetido.

solución idempotente

Para resolver el problema del consumo repetido, Kafka ofrece una solución idempotente. Específicamente, la lógica idempotente se puede implementar en el lado del consumidor para garantizar que el mismo mensaje no se procese repetidamente. Al mismo tiempo, agregar un identificador único (como uuid) en el lado del productor también puede ayudar a evitar la duplicación de mensajes.

Properties props = new Properties();
props.put("enable.idempotence", true); // 开启幂等性
props.put("acks", "all");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("topic", "key", "value");

try {
    
    
    producer.send(record).get();
} catch (ExecutionException | InterruptedException e) {
    
    
    e.printStackTrace();
} finally {
    
    
    producer.close();
}

2.2 El problema de la pérdida de mensajes

fallo al enviar

En Kafka, habrá fallas en el envío de mensajes, como problemas de red, fallas de intermediarios, elecciones de líderes, etc. Estos problemas pueden causar el problema de la pérdida de mensajes.

solución transaccional

Para resolver el problema de la pérdida de mensajes, Kafka proporciona una solución transaccional. Una vez que la transacción se inicia en el lado del productor, el productor puede enviar el mensaje a Kafka a través del modo de transacción y el mensaje no se escribirá en el registro hasta que la transacción se confirme correctamente. Si la confirmación de la transacción falla, todas las operaciones de envío de mensajes anteriores se revertirán.

Properties props = new Properties();
props.put("transactional.id", "my-transactional-id"); // 定义事务ID

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

try {
    
    
    producer.initTransactions(); // 初始化事务
    producer.beginTransaction(); // 开始事务

    ProducerRecord<String, String> record1 = new ProducerRecord<>("topic", "key1", "value1");
    ProducerRecord<String, String> record2 = new ProducerRecord<>("topic", "key2", "value2");
    producer.send(record1);
    producer.send(record2);

    producer.commitTransaction(); // 提交事务
} catch (ProducerFencedException | OutOfOrderSequenceException | AuthorizationException e) {
    
    
    producer.flush();
} catch (KafkaException e) {
    
    
    producer.abortTransaction();
} finally {
    
    
    producer.close();
}

3. Principios de aplicación de transacciones e idempotencia

3.1 El principio de realización de la idempotencia

identificador único del mensaje

El primer paso para lograr la idempotencia en Kafka es asignar un identificador único a cada mensaje. Este identificador puede ser un contador autoincremental o un UUID global único. El cliente de Kafka implementa esta función estableciendo el valor clave del mensaje para garantizar que el valor clave de cada mensaje sea único.

Control de consumo repetido

En Kafka, cuando un mensaje se procesa con éxito, se registra su compensación. Los clientes pueden usar estas compensaciones para evitar consumir el mismo mensaje repetidamente. Además, Kafka Broker también admite el tiempo de caducidad de los mensajes, lo que puede evitar que los mensajes se vuelvan a consumir después de un cierto período de tiempo.

3.2 Principios de implementación transaccional

ciclo de vida de la transaccion

El modelo de transacción de Kafka se implementa en función del mecanismo de transacción proporcionado por la API Producer. Una transacción generalmente incluye los siguientes pasos:

  1. transacción abierta
  2. Enviar un mensaje
  3. pre cometido
  4. transacción de compromiso o reversión

Al iniciar una transacción, Kafka asigna una identificación transaccional a la transacción y envía una solicitud TransactionBegin al clúster de Kafka. Posteriormente, todos los mensajes enviados a la misma transacción se identificarán con el mismo id transaccional.

Después de que el cliente haya enviado todos los mensajes, primero realizará la operación de confirmación previa. En este punto, Kafka escribirá los mensajes en el registro de transacciones, pero no los enviará al corredor inmediatamente. En su lugar, estos mensajes se almacenan en caché localmente en el cliente hasta que el cliente solicita explícitamente una confirmación o reversión de transacción.

Mecanismo de confirmación y reversión de transacciones

En Kafka, el cliente inicia la confirmación y reversión de transacciones. Cuando el cliente llama al método commitTransaction(), Kafka enviará una solicitud de confirmación de transacción al bróker. Una transacción se confirma correctamente si todos los mensajes que participan en la transacción se han procesado correctamente. De lo contrario, la transacción falla y se retrotrae.

Si el cliente revierte la transacción llamando al método abortTransaction(), Kafka enviará una solicitud TransactionAbort al Broker y cancelará todos los mensajes que se hayan enviado pero que aún no se hayan procesado en la transacción.

4. Práctica en Escenarios de Aplicación

4.1 Escenarios de uso

Kafka se utiliza principalmente en los siguientes dos escenarios:

  • Sistema de mensajes : como sistema de mensajes, Kafka puede manejar mensajes masivos, admite el modo de publicación-suscripción y el modo de cola, y puede almacenar mensajes de forma persistente y realizar una transmisión de mensajes eficiente.
  • Recopilación y análisis de registros : Kafka proporciona una solución confiable y eficiente para la recopilación de registros, que puede unificar flujos de datos de varias fuentes, de modo que los datos se puedan recuperar de manera rápida y eficiente en condiciones controlables.

4.2 Métodos prácticos y precauciones

Al usar Kafka, debe prestar atención a los siguientes puntos:

  1. Estrategia de partición razonable . Para temas en el clúster de Kafka, una estrategia de partición razonable puede hacer que la producción y el consumo de mensajes tengan capacidades de equilibrio de carga y escalabilidad más sólidas.
  2. Configuración de réplica apropiada . Establecer una cantidad adecuada de copias puede garantizar la confiabilidad de los datos y también es la clave para equilibrar la carga.
  3. ajuste de rendimiento . El rendimiento es uno de los indicadores clave de Kafka, y se deben realizar ajustes específicos para escenarios específicos para lograr un rendimiento óptimo.

4.3 Evaluación de la confiabilidad y medios de monitoreo

Para garantizar la confiabilidad de Kafka, se deben realizar los siguientes puntos:

  1. Medios apropiados de seguimiento. En el clúster de Kafka, es necesario realizar un seguimiento de los indicadores clave (como la demora, el rendimiento y la tasa de error) en tiempo real y ajustar los parámetros relevantes de acuerdo con la situación real para mejorar el rendimiento.
  2. respaldo de datos Para evitar la pérdida de datos, se debe establecer una estrategia de respaldo de datos. La confiabilidad de los datos se puede garantizar mediante la configuración de mecanismos de copia de seguridad y recuperación de datos.
  3. manejo de errores Cuando Kafka falla, es necesario localizar rápidamente el problema y realizar el manejo de errores correspondiente para evitar la pérdida de datos.

Supongo que te gusta

Origin blog.csdn.net/u010349629/article/details/130934811
Recomendado
Clasificación