La situazione ideale sarebbe quella di far archiviare i messaggi nella coda per un tempo indefinito, fornire la posizione del messaggio mentre recapita i messaggi e consentire di riprendere l'abbonamento da una determinata posizione (anziché solo da ora in avanti). In questo modo, il tuo abbonato può tenere traccia dell'ultimo messaggio che ha elaborato correttamente e iniziare da quella posizione in avanti al suo riavvio. EventStore fa questo. Si tratta di un database di sola aggiunta che si comporta anche come coda a cui è possibile iscriversi.
Supponendo che la tua coda corrente fornisca solo i messaggi degli iscritti da ora in poi, dovrai memorizzare i messaggi non appena entrano (file o database o qualsiasi altra cosa). Quando si inviano messaggi a terze parti, è necessario registrare l'ultimo riuscito (per terza parte) in modo da poter riprendere da lì se si trova troppo indietro o si blocca. Periodicamente, presumo che vorrai eliminare i vecchi messaggi che tutte le terze parti hanno elaborato.
Checkpoint
Puoi salvare il checkpoint (id dell'ultimo messaggio elaborato correttamente) prima o dopo aver consegnato il messaggio.
Il salvataggio del checkpoint prima della consegna viene chiamato Al massimo una volta la consegna, perché è possibile che il messaggio non venga mai consegnato. Ad esempio: Checkpoint viene salvato, ma prima della consegna il computer si blocca. Al riavvio, il checkpoint caricato indica che il messaggio è già stato elaborato e carica quello successivo.
Il salvataggio del checkpoint dopo la consegna viene chiamato Almeno una volta la consegna, perché è possibile recapitare il messaggio più volte. Ad esempio: il messaggio viene inviato, ma il computer si blocca prima che il checkpoint venga salvato. Al riavvio, il checkpoint punta allo stesso messaggio inviato, che verrà nuovamente inviato nuovamente.
Almeno una volta la consegna (salvare il punto di controllo dopo il completamento della consegna) è più sicuro fintanto che i messaggi non inducono effetti collaterali (cioè sono idempotenti). Ad esempio, se il messaggio è CountIncreasedBy: 5, ha un effetto collaterale perché il suo nuovo valore dipende dal vecchio valore e l'elaborazione di questo messaggio più di una volta modificherà il valore sul ricevitore. Tuttavia, se il messaggio dice NewCountSetTo: 37, puoi elaborarlo qualsiasi numero di volte di seguito e avrà sempre lo stesso effetto.
Tuttavia, con "almeno una volta" devi anche guardare i messaggi velenosi. Si tratta di messaggi che si bloccano sempre quando vengono tentati di essere consegnati, quindi non è possibile procedere oltre. Saranno riprovati all'infinito a meno che tu non metta qualcosa a posto per guardarlo.
Si noti inoltre che se non ci sono circostanze in cui le terze parti possono raggiungere (ovvero non è solo traffico burst, ma traffico medio che travolge la terza parte), allora si verificherà lo stesso problema di overflow disco rigido. A quel punto, dovrai utilizzare i metodi offline o semplicemente saltare i messaggi una volta che l'elaborazione è troppo indietro.