Я новичок в akka и собираюсь использовать его в своем новом проекте в качестве механизма репликации данных.
В этом сценарии есть главный сервер и сервер репликации данных.Реплицируемые данные должны содержать те же данные, что и основные.Каждый раз, когда в мастере происходит изменение данных, он отправляет сообщение об обновлении на сервер репликации.Здесь главный сервер - Отправитель, а Реплицирующий сервер - Получатель.
Но после копания документов я все еще не уверен, как удовлетворить следующие варианты использования:
- Когда происходит сбой получателя, отправитель должен накапливать сообщения для отправки, ни одно сообщение не должно быть потеряно.Он должен иметь возможность подключиться к получателю позже и продолжить с последним успешным сообщением.
- , когда отправитель падает, он должен перезапуститься, и никакие сообщения между перезапусками не будут потеряны.
- Сообщения обрабатываются в том же порядке, в котором они были отправлены.
Итак, мой вопрос, как настроить akka для создания отправителя и получателя, которые могли бы это сделать?
Я не уверен, что актер с DurableMessageBox мог решить эту проблему.Если это возможно, как я могу смоделировать описанные выше ситуации для тестирования?
Обновление:
После прочтения документов, на которые указал Виктор, я теперь понял, что ятребуемый шаблон единожды и единожды , который является чрезвычайно дорогостоящим.
В документах akka говорится, что
Фактические транспорты могут обеспечить более сильную семантику,но самое большее один раз - это семантика, которую вы должны ожидать.Альтернативы могут быть один раз и только один раз , что является чрезвычайно дорогостоящим, или , по крайней мере, один раз , что по существу требует идемпотентности обработки сообщений, что является проблемой на уровне пользователя.
Таким образом, чтобы добиться гарантированной доставки, мне может понадобиться другое решение MQ (например, Kafka ) или попытаться внедрить один раз итолько один раз с DurableMessageBox, и посмотрите, можно ли решить эту сложность с моим конкретным вариантом использования.