Reintentos

Los clientes de Kafka proporcionan lógica de reconexión, pero debe habilitar de forma explícita las reconexiones para los productores. Para más información, consulte la propiedad retries. Las conexiones se restauran en 60 segundos.

Duplicados

La habilitación de los reintentos puede dar como resultado mensajes duplicados. Dependiendo de cuándo se pierde una conexión, es posible que el productor no pueda determinar si un mensaje ha sido procesado correctamente por el servidor y por lo tanto debe volver a enviar el mensaje al reconectarse. Diseñe aplicaciones para que esperen mensajes duplicados.

Si no se pueden tolerar duplicados, puede utilizar la característica de productor idempotent (a partir de Kafka 1.1) para evitar duplicados durante los reintentos. Para más información, consulte la propiedad enable.idempotence.

Orientación específica para el plan estándar

Para obtener información de orientación de rendimiento, consulte Límites y cuotas - Estándar.

Orientación específica para el plan empresa

Para obtener información de orientaciones para un mejor rendimiento, consulte Límites y cuotas - Empresa.

Medida

Instrumentar las aplicaciones para ser conscientes de cómo se están comportando. Por ejemplo, el número de mensajes enviados y recibidos, los tamaños de los mensajes y los códigos de retorno. Entender el uso de una aplicación le ayuda a configurar adecuadamente sus recursos, como por ejemplo el tiempo de retención de los mensajes por temas.

Saturación

A medida que se acerca al límite del tráfico que se puede producir en el clúster, los productores empiezan a ser regulados, aumenta la latencia y, en última instancia, se producen errores como los errores de tiempo de espera excedido. Según la configuración, es posible que también haya repercusión en la coherencia y la durabilidad de los mensajes. Para obtener más información, consulte Coherencia y durabilidad de los mensajes.

Modalidad de productor acks

Aunque todos los mensajes se replican, las aplicaciones pueden controlar la solidez con la que los mensajes que producen se transfieren al servicio utilizando la propiedad del modo de productor ( acks ). Esta propiedad proporciona una opción entre la velocidad y el riesgo de perder mensajes. Con Kafka 3.0, el valor de cliente predeterminado es acks=all (antes de esta versión era acks=1). El valor acks=all significa que el productor devuelve un resultado satisfactorio, tan pronto como el intermediario al que está conectado y al menos otro intermediario en el clúster, ha reconocido que ha recibido el mensaje. La ventaja de utilizar acks=all es que ofrece el nivel más alto de durabilidad y, por lo tanto, protección contra la pérdida de datos de mensaje.

Réplicas en sincronización

En la configuración que Event Streams utiliza, Kafka elige un intermediario como líder para cada réplica de partición y otros dos intermediarios como seguidores. Los datos de mensaje de los clientes se envían al líder de la partición y se replican a los seguidores. Si los seguidores se mantienen al día con el líder, se consideran réplicas "en sincronización". El líder, por definición, siempre se considera que está sincronizado.

Si el líder de una partición deja de estar disponible, quizás debido al mantenimiento que se aplica al intermediario, Kafka elige automáticamente una de las otras réplicas en sincronización para convertirse en el nuevo líder. Este proceso se produce rápidamente y lo manejan automáticamente los clientes de Kafka.

Elecciones de líderes impuras

Event Streams inhabilita las elecciones de líder no limpias. Esta configuración no se puede cambiar.

El término elección de líder no limpia describe cómo Kafka responde en una situación en la que toda la réplica en sincronización para una partición deja de estar disponible. Cuando las elecciones de líder no limpias están habilitadas, Kafka se recupera haciendo que la primera réplica pase a estar disponible como líder para la partición, independientemente de si está sincronizada o no. Esto puede hacer que se pierdan datos de mensaje si la réplica seleccionada para ser líder no ha replicado todos los datos de mensaje del líder anterior. Cuando las elecciones de líder no limpias están inhabilitadas (como es el caso de Event Streams), Kafka espera a que una réplica en sincronización esté disponible y elige que sea el nuevo líder de la partición. Esto evita la posibilidad de pérdida de datos de mensaje que se puede producir cuando se habilitan elecciones de líder no limpias. La compensación es que la recuperación puede tardar más tiempo porque es posible que Kafka tenga que esperar a que un intermediario específico vuelva a estar en línea antes de que una partición esté disponible para que los clientes produzcan y consuman datos de mensajes.