Обработка ошибок диспетчера CQRS EventStore

Я смотрел на 2 сценария: A в порядке, B не уверен.

Сценарий A: имитация перезапуска приложения после фиксации перед отправкой

  1. Запустить магазин событий
  2. Зафиксировать изменение
  3. Событие не отправлено
  4. Остановить хранилище событий
  5. Запустить магазин событий

Событие De commit отправляется снова на шаге 5. Это отлично работает, и я вижу это также в коде диспетчера.

Сценарий B: имитация ошибки шины

  1. Запустить магазин событий
  2. Зафиксировать изменение 1
  3. Исключение в диспетчере
  4. Зафиксировать изменение 2
  5. Отправка в порядке

В этом случае я не могу найти поведение, а также задаюсь вопросом, является ли это допустимым случаем: это могло произойти только в том случае, если в коде шины была ошибка.

Есть ли триггер, который повторит попытку отправки, или мне нужно написать код, чтобы справиться с этим, или мои рассуждения ошибочны?


cqrs neventstore
person SvR    schedule 11.04.2011    source источник
comment
Мне любопытно, откуда вы берете шаблоны, которые используете. Я не слышал о некоторых из этих концепций, поскольку они относятся к CQRS. Указатель приветствуется. Спасибо!   -  person Erick T    schedule 19.04.2012

Ответы (1)


arrow_upward
7
arrow_downward

Ваша оценка сценария A верна, в условиях сбоя, таких как перезапуск приложения или компьютера/прекращение процесса, когда процесс запускается снова, он обнаруживает неотправленные коммиты и передает их диспетчеру.

Сценарий B несколько сложнее. Проблема в том, что EventStore не является шиной, поэтому вопрос о том, как обрабатывать ошибки в шине, нельзя решить в самом EventStore. Кроме того, поскольку существует несколько реализаций шины, я не хочу связывать EventStore с какой-либо конкретной реализацией. Некоторые пользователи могут даже не использовать шину сообщений; вместо этого они могут решить использовать вызовы RPC.

Вопрос, который у вас действительно возникает, заключается в том, как следует обрабатывать сбои шины и, соответственно, сбои очереди? EventStore имеет интерфейс IPublishCommits. Когда событие фиксируется, оно передается диспетчеру. Диспетчеры просто несут ответственность за пометку события как отправленного после того, как оно правильно и успешно обработано реализацией IPublishCommits.

Лучший способ справиться с временными сбоями шины и очереди — реализовать шаблон прерывателя цепи в реализации IPublishCommits, который повторяет попытки до тех пор, пока все снова не начнет работать. Для более серьезных проблем, таких как сбои сериализации, вы можете захотеть зарегистрировать какой-либо критический сбой, который немедленно уведомит администратора. Опять же, неприятная проблема во всем этом заключается в том, что EventStore не может знать обо всех особенностях вашей ситуации.

person Jonathan Oliver    schedule 11.04.2011