prefacio
Con el desarrollo de los microservicios, el middleware de mensajes de Kafka es un medio importante para el desacoplamiento asincrónico y la reducción de los picos de tráfico. Al mismo tiempo, cómo garantizar que los mensajes no se pierdan también se ha convertido en un problema que debe resolverse. Las siguientes siete sugerencias le ayudarán a resolverlo.
sugerencia
Establecer la función de devolución de llamada cuando el productor del mensaje envía un mensaje
Configurar la función de devolución de llamada es en realidad un mecanismo de confirmación de mensajes, que tiene las siguientes funciones:
- Si el mensaje de escucha llega con éxito al intermediario
- Grabe el registro de mensajes en mongo, que es fácil de localizar el problema
- Algunos mecanismos de compensación de mensajes se pueden realizar adecuadamente, como el reenvío de mensajes fallidos.
Establecer el parámetro acks
acks es un parámetro del Productor que representa la definición de mensajes "confirmados". Los valores que se pueden configurar son todos, 0, 1, -1. Se puede configurar en combinación con el negocio real
#procedure要求leader在考虑完成请求之前收到的确认数，用于控制发送记录在服务端的持久化，其值可以为如下：
#acks = 0 如果设置为零，则生产者将不会等待来自服务器的任何确认，该记录将立即添加到套接字缓冲区并视为已发送。在这种情况下，无法保证服务器已收到记录，并且重试配置将不会生效（因为客户端通常不会知道任何故障），为每条记录返回的偏移量始终设置为-1。
#acks = 1 这意味着leader会将记录写入其本地日志，但无需等待所有副本服务器的完全确认即可做出回应，在这种情况下，如果leader在确认记录后立即失败，但在将数据复制到所有的副本服务器之前，则记录将会丢失。
#acks = all 这意味着leader将等待完整的同步副本集以确认记录，这保证了只要至少一个同步副本服务器仍然存活，记录就不会丢失，这是最强有力的保证，这相当于acks = -1的设置。
spring.kafka.producer.acks=all
复制代码Establecer el parámetro de reintentos
Se recomienda un valor mayor. Lo mismo es el parámetro del Productor. Cuando se produce fluctuación en la red, el envío de mensajes puede fallar. En este momento, el Productor configurado con reintentos puede reintentar automáticamente el envío de mensajes para evitar la pérdida de mensajes tanto como sea posible.
spring.kafka.producer.retries=3
复制代码设置unclean.leader.election.enable = false。
Este es un parámetro del lado del Broker. En la iteración de la versión kafka, la comunidad ha modificado repetidamente su valor predeterminado, lo que antes era controvertido. Controla qué corredores son elegibles para postularse para el líder de la división. Si un corredor está muy por detrás del líder original, causará la pérdida de mensajes una vez que se convierta en el nuevo líder. Por lo tanto, generalmente es necesario establecer este parámetro en falso.
unclean.leader.election.enable = false
复制代码Establezca replication.factor >= 3.
Este también es un parámetro en el lado del corredor. Guarde varias copias de la redundancia de mensajes, no hay mucho que explicar.
replication.factor >= 3
复制代码Establezca min.insync.replicas > 1.
Parámetro del lado del intermediario, que controla en cuántas réplicas se debe escribir el mensaje antes de que se considere "confirmado". Establézcalo en mayor que 1 para mejorar la durabilidad del mensaje. No utilice el valor predeterminado de 1 en un entorno de producción. Asegúrese de replication.factor > min.insync.replicas. Si los dos son iguales, mientras una réplica esté fuera de línea, la partición completa no funcionará. Se recomienda configurar replication.factor = min.insync.replicas + 1.
Asegúrese de que el consumo de mensajes se haya completado y luego enviado.
Hay un parámetro enable.auto.commit en el lado del consumidor, es mejor establecerlo en falso y manejar la actualización de compromiso del desplazamiento por sí mismo.