Комментарии 2
А можете рассказать каким образом гарантируется целостность сохраненного лога событий в случае при падениях и network partitioning отдельных нод кластера? В частности, если так вышло, что кластер решил, что нода недоступна и поднял новых экземпляров акторов на нормальных нодах, но на недоступной ноде еще не успел сработать split brain resolver и те же акторы еще живы и еще продолжают писать в event log - будут побитые данные, или storage будет давать отлуп на попытки записи с тем же ключом, или это зависит от реализации storage?
Наверное общего ответа для вас у меня нету.
Для частного случая (из примера) могу предположить. В простейшем случае, если у нас пропала связь между двумя akka cluster node, но разные consumer'ы продолжают читать каждый свои партиции, то у них и не возникнет необходимости создавать state актор для данных из другой партиции. То есть, каждая нода обрабатывает только свои сущности (конкретные банки).
В случае, если еще и второй consumer отвалится, то да, спустя какое-то время kafka consumer group перебалансирует партиции на первую ноду и тут начнут обрабатываться данные и создаваться state акторы. Но в моем понимании, это произойдет только после того как вторая нода перестанет читает эти партиции и поэтому там не может возникнуть параллельного потока тех же данных.
Вообще, я понимаю, что после серии перебалансировок consumer-group и split brain для akka cluster может появиться ситуация, когда одни те же данные пройдут дважды по разным state. В нашем случае, операция обновления стейта является идепотентой и поэтому не так страшно если мы несколько раз получим одно и то же событие обновления state - лишь бы не потеряли и не переупорядочили.
В общем случае, в event driven предлагают использовать идемпотентные операции, механизмы дедубликации и механизмы компенсаций. Я предпочитаю верить, что в кокнертных ситуациях всегда можно найти решение.
Построение потоковой stateful обработки данных на Akka