Confirmación de mensajes
La confirmación informa al broker de que una entrega se ha recibido o procesado según la regla acordada.
Una confirmación de mensaje indica al broker cuándo puede considerar completada una entrega. Son decisivos tanto la dirección de la confirmación como el momento en que la aplicación la envía.
En RabbitMQ, un consumidor utiliza una confirmación positiva manual, como basic.ack, para confirmar al broker su procesamiento. Un publisher confirm, en cambio, confirma al emisor la aceptación por parte del broker. Eso no demuestra que la aplicación receptora haya terminado su tarea.
Entre guardar y confirmar
En un flujo ficticio, un servicio procesa el mensaje E-42, guarda de forma duradera el cambio necesario en la base de datos y después lo confirma. Si confirma primero y falla antes de guardar, el broker puede considerar la entrega completada aunque falte el cambio.
También importa el caso inverso: si el cambio se guarda pero la confirmación se pierde, puede haber una nueva entrega. Con confirmaciones manuales, RabbitMQ vuelve a poner en cola los mensajes no confirmados tras el cierre de una conexión o un canal. Por tanto, el servicio debe gestionar la repetición sin producir dos veces el mismo resultado de negocio.
La confirmación automática de RabbitMQ no espera a que termine el trabajo de la aplicación. El modo elegido debe ajustarse a la protección deseada frente a la pérdida de trabajo. La confirmación del consumidor tampoco demuestra que todos los servicios posteriores o una notificación externa hayan funcionado correctamente.
Fuentes
Términos relacionados
- Cola de mensajesUna cola de mensajes almacena temporalmente mensajes hasta que un consumidor los toma para procesarlos.
- Inbox transaccionalUn inbox transaccional usa registros duraderos de mensajes para proteger el procesamiento local frente a entregas duplicadas.
- Variación aleatoria entre reintentosEl jitter de reintentos varía aleatoriamente las esperas para repartir los reintentos y reducir las solicitudes simultáneas de varios clientes.
- Espacio de cliente de pruebasUn espacio lógico delimitado de una aplicación multitenant, configurado para comprobaciones.
- Reenvío de webhookEl reenvío de webhook vuelve a transmitir una notificación. La recuperación deliberada y los ataques de repetición requieren comprobaciones diferentes.
- Clave de idempotenciaUna clave de idempotencia identifica repeticiones de una misma solicitud. Su efecto depende del ámbito, la conservación y las reglas de la API.
Artículos sobre el tema








APIs e integración con ASES
ERP, CRM y tienda bien conectados

