Проблема параллелизма при получении событий между несколькими экземплярами

Question

Я новичок в концепции источников событий, поэтому есть пара моментов, которые я не понимаю.Один из них - как справиться со следующим сценарием:

У меня есть 2 экземпляра службы.Они оба слушают очередь событий.Есть два сообщения: CreateUser и UpdateUser.Первый экземпляр выбирает CreateUser, а второй - UpdateUser.По какой-то причине второй экземпляр будет обрабатывать свою команду быстрее, но пользователь не будет обновляться, поскольку он не был создан.

Что я здесь не так делаю?

Answer 1

Что я здесь не так делаю?

Обзор: Условия гонки не существуют

Разница во времени в микросекундахне должно иметь никакого значения для основного делового поведения.

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

Как правило, следует понимать, что события поддерживают несколько наблюдателей - все подписчики могут видеть все события.,Таким образом, очередь с конкурирующими потребителями не является обычным подходом, если только вы не пытаетесь распределить определенного подписчика по нескольким процессам.

Answer 2

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

Оба они слушают очередь событий.

И эта очередь должна это поддерживать.Примером являются лазурные очереди, где я могу прослушать И СКАЗАТЬ ОЧЕРЕДЬ, чтобы не показывать событие кому-либо еще в течение X секунд (этого мне достаточно, чтобы решить, обработал я это или нет).Если я не отвечаю -> событие переустанавливается после этого времени.Если я сначала убью его, параллелизма не будет.

Итак, вам нужна внутренняя очередь, которая может это обработать.