Как избежать параллелизма по статусу агрегатов с помощью Rebus в кластере серверов

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

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

Это позволит вашей совокупности либо

а) принять изменения в любом порядке (что обычно предпочтительнее — делает вашу систему более терпимой) или б) отклонить недопустимое изменение

Если агрегат отклоняет изменение, это может быть реализовано путем создания исключения. И затем в обработчике Rebus, который ловит это исключение, вы можете, например. await bus.Defer(TimeSpan.FromSeconds(5), theMessage), что приведет к повторной доставке через пять секунд.

Вы никогда не должны полагаться на порядок сообщений в среде служебной шины/очереди/обмена сообщениями.

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

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

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

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

Надеюсь, это поможет...

"точно такая же последовательность, как они были сохранены в автобусе"

Просто почему?

Будете ли вы полагаться на журналы вашего HTTP-сервера, чтобы узнать, какая команда на самом деле достигла агрегата первой? Нет, потому что это совершенно ненадежно, как и с хотя бы одной гарантией доставки, и это тоже не имеет значения.

Именно ваше хранилище событий и/или нормальное состояние сохраняемости должно быть источником истины, когда дело доходит до знания последовательности событий. Порядок команд не должен иметь большого значения.

Предполагая оптимистичный параллелизм, если агрегату не разрешен переход от A к C, тогда он должен охранять этот инвариант, и когда команда TransitionToStateC поразит его в состоянии A, он будет просто отклонен.

С другой стороны, если A->C->B переходов действительны, и это порядок, полученный вашим агрегатом, то это то, что произошло с точки зрения домена. На самом деле не должно иметь значения, какая команда была опубликована на шине первой, точно так же, как не имеет значения, какой пользователь первым выполнил команду из пользовательского интерфейса.

«В моем сценарии вызовы для определенного агрегата абсолютно последовательны, и я должен гарантировать, что они выполняются в том же порядке».

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

Почему:

executeAsync(command1)
executeAsync(command2)
executeAsync(command3)

Когда вы хотите:

execute(command1)
execute(command2)
execute(command3)

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