Akka Persistence riproduce gli eventi creati in base ai comandi ricevuti. Gli eventi vengono generati dai messaggi di comando dopo la convalida e non dovrebbero essere in grado di creare stati di attori non validi.
Ciò significa che non vengono riprodotti i messaggi iniziali ricevuti (comandi), ma è possibile mantenere gli eventi meno costosi da applicare per ricostruire lo stato di un attore dopo l'arresto. Inoltre, è possibile utilizzare snapshots per ripristinare direttamente lo stato.
Modifica: Come menzionato i commenti è vero che solo lo stato dell'attore è persistente e sopravvive all'incidente. Questo stato riflette solo i messaggi consumati e non quelli che risiedono ancora nella cassetta degli attori.
Tuttavia, invece di inviare messaggi a un attore che verrebbe quindi archiviato in una cassetta postale duratura, un'alternativa potrebbe essere per il "destinatario" di estrarre messaggi da un attore persistente che memorizza l'elenco di messaggi come parte del suo stato.
UntypedPersistentActorWithAtLeastOnceDelivery come parte della persistenza akka offre un'altra possibilità in cui il mittente si prende cura dei messaggi persistenti.
Mi rendo conto che non si tratta di sostituzioni drop-in per cassette postali durevoli poiché richiedono un ripensamento del sistema. Tirare il lavoro dai consumatori ha funzionato per me finora. Inizialmente abbiamo considerato anche i prodotti Message Queue (RabbitMQ con code resistenti) ma dal momento che i nostri elementi di lavoro iniziali provengono da un db, possiamo occuparci di un crash di akka senza messaggi durevoli.
fonte
2015-12-30 12:44:37
La funzionalità di persistenza è diversa dalla cassetta postale duratura. Hai ancora la coda in memoria che andrà persa se il nodo si arresta in modo anomalo e il messaggio non è stato consumato (per essere persistente). – Jags