What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Con el commit manual de offsets, el momento en que confirmas el offset determina qué trabajo se repite si el consumidor se cae. La regla práctica es confirmar solo después de haber completado el procesamiento que quieres dar por hecho. Así, una caída posterior hace que el grupo retome desde el último punto confirmado y, como mucho, reprocese registros que todavía no tenían commit.
Qué significa realmente confirmar un offset
En Kafka, leer un registro y confirmar su offset son dos acciones separadas. El consumidor recibe registros con poll(), los procesa y, en algún momento, registra en el grupo hasta dónde ha llegado. Ese registro de progreso es lo que usa el grupo cuando un consumidor se reinicia o una partición se reasigna a otro miembro.
As an Amazon Associate I earn from qualifying purchases.
Por eso el commit no es un detalle de implementación: es una decisión de recuperación. Si confirmas antes de terminar el trabajo y el proceso cae, al reanudar puede saltarse trabajo que nunca llegó a completarse. Si terminas el trabajo y cae antes del commit, el registro se procesará de nuevo. El commit manual te permite elegir cuál de esos dos riesgos aceptas, de acuerdo con la semántica de tu aplicación.
Auto commit: el comportamiento por defecto
Según la documentación de configuración de Apache Kafka 2.6, enable.auto.commit tiene por defecto el valor true, de modo que los offsets se confirman periódicamente en segundo plano. La frecuencia la controla auto.commit.interval.ms, cuyo valor por defecto en esa versión es 5000 ms. Ambos valores son los de Kafka 2.6; si usas otra versión del cliente, verifica la documentación correspondiente antes de asumir la misma configuración.
#1 Best Overall
El problema del auto commit es que el momento de la confirmación depende del reloj, no de tu lógica. El intervalo puede dispararse mientras un lote sigue en curso, de modo que el offset confirmado no refleja necesariamente el trabajo realmente terminado.
Cómo desactivar el auto commit
- Establece
enable.auto.commitenfalseen las propiedades del consumidor. En Java puedes usar la constanteConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG. - Confirma offsets de forma explícita desde tu código con
commitSyncocommitAsync, tal como se muestra más abajo. - Comprueba en pruebas que, tras reiniciar el consumidor, la lectura reanuda desde el punto que esperas.
Properties props = new Properties();
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
// ... resto de la configuración (bootstrap.servers, group.id, deserializadores)
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(List.of("pedidos"));
while (true) {
ConsumerRecords<String, String> registros = consumer.poll(Duration.ofMillis(500));
for (ConsumerRecord<String, String> r : registros) {
procesar(r);
}
consumer.commitSync();
}En este patrón, el commit se ejecuta solo cuando el lote completo se ha procesado sin excepciones. Si procesar lanza un error a mitad del lote, el commit no llega a ejecutarse y, al reiniciar, el lote entero se vuelve a leer. Si necesitas granularidad mayor, confirma por registro o por grupo de registros con offsets explícitos.
Qué offset confirmar
Esta es la confusión más frecuente. Cuando confirmas un mapa de offsets explícito, el valor que escribes es el próximo offset que se consumirá, no el del último registro procesado. Por eso se suma uno.
Recommended Free Tools
Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
offsets.put(new TopicPartition(r.topic(), r.partition()),
new OffsetAndMetadata(r.offset() + 1));
consumer.commitSync(offsets);Si usas subscribe con gestión automática de grupo, confirma solo offsets de particiones que sigan asignadas al consumidor. Un offset de una partición que ya se ha reasignado puede provocar un fallo en el commit.
Rank #3
Cuándo confirmar: tres escenarios
| Momento del commit | Si el consumidor cae después de procesar pero antes de confirmar | Si el consumidor cae después de confirmar pero antes de terminar el trabajo |
|---|---|---|
| Después de procesar el lote | El lote se vuelve a procesar (duplicados posibles). | No aplica: el commit no llega a ejecutarse antes de terminar el trabajo. |
| Antes de procesar el lote | No aplica: el offset ya está confirmado. | El trabajo pendiente se salta y no se completa. |
La elección depende de si tu operación tolera repeticiones. Un envío de correo o un cargo en un proveedor externo no se corrige con un commit; requiere idempotencia o una coordinación explícita con el sistema externo.
commitSync frente a commitAsync
| Eje | commitSync |
commitAsync |
|---|---|---|
| Espera | Bloquea hasta que termina, falla o expira el timeout. | No bloquea; el resultado se comunica al callback si se proporciona. |
| Control del resultado | El flujo puede reaccionar al retorno o a la excepción antes de continuar. | El flujo sigue y debes observar el callback para conocer el resultado. |
| Caso típico | Secuencias explícitas y fáciles de razonar. | Cuando no quieres bloquear el hilo de consumo. |
Según el Javadoc de KafkaConsumer (versión 4.2.0), las llamadas asíncronas sucesivas se envían en el orden en que se invocan. Aun así, una llamada commitAsync no demuestra por sí sola que el commit haya tenido éxito.
consumer.commitAsync((offsets, excepcion) -> {
if (excepcion != null) {
registrarFallo(excepcion);
}
});Ninguna de las dos opciones es universalmente superior. Si tu bucle de consumo es sensible a la latencia, commitAsync reduce la espera; si prefieres un flujo lineal, commitSync es más fácil de auditar.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rebalances y fallos de commit
Un rebalance puede invalidar la asignación de particiones que el consumidor tenía en el momento de confirmar. En ese caso, el commit falla, y el API Java lo señala con CommitFailedException en el caso síncrono. Trátalo como un escenario normal, no como un error excepcional: diseña el ciclo de vida del consumidor para cerrar limpiamente, o para reanudar, sin asumir que la asignación seguirá vigente.
- Captura excepciones de commit y decide si reintentar, descartar el lote o detener el consumidor.
- Registra los fallos con suficiente contexto (partición, offset, grupo) para diagnosticar reprocesamientos.
- Evita procesar un lote largo sin ninguna señal de vida si el grupo puede expulsar al consumidor por timeout.
Límites de la garantía
El commit manual te da control sobre el punto de recuperación dentro de Kafka. No convierte el procesamiento en exactamente una vez por sí solo. Si el resultado de cada registro se escribe en una base de datos u otro sistema externo, la coherencia total depende de cómo coordines esa escritura con el commit, por ejemplo mediante escrituras idempotentes o transacciones que incluyan el offset.
La documentación consultada cubre la API Java de KafkaConsumer y la configuración de Kafka 2.6. No describe los clientes de Python, Go o .NET, ni los patrones transaccionales completos. Antes de trasladar nombres de métodos o garantías a otro lenguaje, consulta la documentación de ese cliente.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute
