Conferma dei messaggi
La conferma comunica al broker che una consegna è stata ricevuta o elaborata secondo la regola concordata.
Una conferma di messaggio indica al broker quando può considerare conclusa una consegna. Contano sia la direzione della conferma sia il momento in cui l’applicazione la invia.
In RabbitMQ, un consumer usa una conferma positiva manuale come basic.ack per confermare al broker la propria elaborazione. Un publisher confirm conferma invece al mittente l’accettazione da parte del broker. Questo non dimostra che l’applicazione destinataria abbia terminato il proprio compito.
Tra il salvataggio e la conferma
In un flusso fittizio, un servizio elabora il messaggio E-42, salva in modo duraturo la modifica necessaria nel database e solo dopo invia la conferma. Se conferma prima e si arresta prima del salvataggio, il broker può già considerare conclusa la consegna anche se manca la modifica.
Conta anche il caso inverso: se la modifica è salvata ma la conferma va persa, può seguire una nuova consegna. Con le conferme manuali, RabbitMQ rimette in coda i messaggi non confermati dopo la chiusura della connessione o del canale. Il servizio deve quindi gestire la ripetizione senza produrre due volte lo stesso risultato applicativo.
La conferma automatica di RabbitMQ non attende che l’applicazione finisca il lavoro. La modalità scelta deve corrispondere alla protezione desiderata contro la perdita del lavoro. La conferma del consumer non dimostra neppure che tutti i servizi successivi o una notifica esterna siano andati a buon fine.
Fonti
Termini correlati
- Coda di messaggiUna coda di messaggi mantiene i messaggi in attesa che un consumatore li prenda in carico per elaborarli.
- Transactional inboxUna transactional inbox usa registrazioni durature dei messaggi per proteggere l’elaborazione locale dalle consegne duplicate.
- Jitter nei retryIl jitter varia casualmente le attese tra i retry per distribuire i nuovi tentativi e ridurre le richieste simultanee di più client.
- Tenant di testUn ambito cliente logicamente delimitato di un’applicazione multitenant, configurato per verifiche.
- Reinvio di webhookIl reinvio di webhook trasmette nuovamente una notifica. Il recupero intenzionale e gli attacchi di replay richiedono verifiche diverse.
- Chiave di idempotenzaUna chiave di idempotenza identifica i tentativi ripetuti della medesima richiesta. Ambito, conservazione e regole dell’API ne determinano l’effetto.
Articoli sul tema








API & integrazione con ASES
ERP, CRM e negozio online collegati in modo pulito

