Solución:
-
@KafkaListeneres un “POJO” basado en mensajes que agrega cosas como conversión de carga útil, coincidencia de argumentos, etc. Si implementaMessageListenersolo puedes conseguir lo crudoConsumerRecordde Kafka. Consulte la anotación de @KafkaListener. -
Sí, la simultaneidad representa el número de subprocesos; cada hilo crea un
Consumer; corren en paralelo; en su ejemplo, cada uno obtendría 2 particiones.
También debemos considerar cualquier cosa si consumimos en paralelo.
Su oyente debe ser seguro para subprocesos (ningún estado compartido o cualquier estado de este tipo debe estar protegido por bloqueos).
-
No está claro qué quiere decir con “manejar eventos de reequilibrio”. Cuando se produce un reequilibrio, el marco comprometerá las compensaciones pendientes.
-
No hace ninguna diferencia; oyente de mensajes vs. el oyente por lotes es solo una preferencia. Incluso con un oyente de mensajes, con el modo ack MANUAL, las compensaciones se confirman cuando se han procesado todos los resultados de la encuesta. Con el modo MANUAL_IMMEDIATE, las compensaciones se confirman una por una.
Q1:
De la documentación,
La anotación @KafkaListener se utiliza para designar un método de bean como escucha para un contenedor de escucha. El bean está envuelto en un MessagingMessageListenerAdapter configurado con varias características, como convertidores para convertir los datos, si es necesario, para que coincidan con los parámetros del método.
Puede configurar la mayoría de los atributos en la anotación con SpEL utilizando “# {…} o marcadores de posición de propiedad ($ {…}). Consulte el Javadoc para obtener más información”.
Este enfoque puede ser útil para oyentes POJO simples y no es necesario implementar ninguna interfaz. También está habilitado para escuchar cualquier tema y partición de forma declarativa utilizando las anotaciones. También puede devolver potencialmente el valor que recibió, mientras que en el caso de MessageListener, está obligado por la firma de la interfaz.
P2:
Idealmente sí. Sin embargo, si tiene varios temas para consumir, se vuelve más complicado. Kafka usa de forma predeterminada RangeAssignor, que tiene su propio comportamiento (puede cambiar esto; consulte más detalles a continuación).
Q3:
Si su consumidor muere, habrá reequilibrio. Si reconoce manualmente y su consumidor muere antes de realizar compensaciones, no necesita hacer nada, Kafka se encarga de eso. Pero podrías terminar con algunos mensajes duplicados (al menos una vez)
Q4:
Depende de lo que entiendas por “rendimiento”. Si te refieres a la latencia, entonces consumir cada registro lo más rápido posible será el camino a seguir. Si desea lograr un alto rendimiento, el consumo de lotes es más eficiente.
Había escrito algunas muestras usando Spring Kafka y varios oyentes: consulte este repositorio