Обработка событий гарантируется использованием источников событий в постоянном сущности и отслеживании смещения при обработке на стороне чтения.
Когда ваш постоянный обработчик команд сущности продолжает события, каждое из событий сохраняется с упорядоченным "offset".
Процессоры на стороне чтения работают путем опроса базы данных для событий со смещениями, превышающими последнее смещение, которое уже было обработано. Поскольку все события и каждое последнее смещение процессора на стороне чтения сохраняются в базе данных, это гарантирует, что события не будут пропущены, даже если процессор на стороне чтения будет аварийно завершен и перезагружен.
ЛАГА Кассандра чтения сторона процессоры возвращают CompletionStage или Future, которые производят список Cassandra BoundStatement экземпляров, и они выполняются в атомном обновлении пакетного наряду с смещением обновления. Пока все эффекты вашего обработчика событий на стороне чтения фиксируются в списке произведенных обновлений, это гарантирует, что событие будет обработано эффективно один раз: если часть обновления не удалась, он будет автоматически повторен.
Если вы делаете что-либо еще в своем обработчике событий, вам нужно быть уверенным, что обновление смещения произойдет только в том случае, если обработчик событий прошел успешно. CompletionStage или Future возврат обработчика событий должен выполняться только после того, как ваш побочный эффект будет выполнен, и успех или сбой в работе должны быть распространены. Имейте в виду, что обработчик событий будет повторно принят, если смещение не будет обновлено, поэтому, если ваш обработчик событий взаимодействует с внешней службой, например, вам нужно быть уверенным, что он идемпотент.
Вы также должны знать, как конечная консистенция может повлиять на вещи. akka-persistence-cassandraconfiguration reference имеет некоторые детали:
возвращается поток событий упорядочено смещения (метки времени), что соответствует в том же порядке, что и журнал записи хранится события, с погрешностью в связи с Clock Skew между различными узлы. Те же самые элементы потока (в том же порядке) возвращаются для выполнения целых исполнений запроса в наилучшей степени. Запрос использует Cassandra Materialized Просмотр запроса, и это в конечном итоге является последовательным, поэтому разные запросы могут видеть различные события для последних событий, но в итоге результат будет упорядочен по отметке времени (колонка времени Cassandra timeuuid). Чтобы компенсировать возможную согласованность, запрос задерживается, чтобы не читать последние события, продолжительность этой задержки определяется этим свойством конфигурации .
Однако, это только лучшие усилия и в случае сетевых разделов или других вещей, которые могут задержать обновления материализованного представления события могут быть доставлены в другом порядке (не строго по их временной меткой).
Важное следствием является то, что если задержка возможной последовательности больше, чем сконфигурированная возможной задержка консистенции (возможно, из-за разделение сети между узлами Cassandra), есть возможность событий, которые «потеряли». Обработчик на стороне чтения, возможно, уже обработал новое событие и сохранил его смещение до того, как более старое событие было доставлено на узел, из которого он считывается. Возможно, вам придется настроить свою конфигурацию соответствующим образом.