Как обрабатывать порядок сообщений в nservicebus?

Я пытаюсь найти способ обработки сообщений в том порядке, в котором они были отправлены отправителем, поскольку NServiceBus не гарантирует, что сообщения будут обрабатываться в определенном порядке.

Отправитель — это система заказов, которая публикует команды createOrder и reviseOrder. Отправитель позволяет пользователю отправить несколько редакций в один и тот же заказ, чтобы в очереди одновременно могли находиться ревизия 4 и ревизия 3. Каждая ревизия имеет номер ревизии и связанный с ней код причины, который управляет некоторой бизнес-логикой, поэтому мы не можем игнорировать какие-либо ревизии или, по крайней мере, часть причины.

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

  1. Сохраните номер редакции вместе с записью назначения. Отправитель отправляет свой номер версии в каждом сообщении о версии. Обработчик сравнивает номера версий отправителя и получателя, если они совпадают, запись обновляется, в противном случае сообщение помещается в конец очереди. При таком подходе, если сообщение ревизии 2 завершается ошибкой и попадает в очередь ошибок, ревизия 3 никогда не будет обработана.

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

Как мы разрабатываем для этого сценария?
Есть ли какие-нибудь идеи о том, как обрабатывать сообщения о неудачных версиях?

Некоторые рекомендации действительно ценятся.

Спасибо.


.net servicebus esb nservicebus msmq
person maddog    schedule 06.09.2013    source источник

Ответы (1)


arrow_upward
9
arrow_downward

Из коробки одно из основных правил NserviceBus заключается в том, что вы должны создавать свои системы таким образом, чтобы порядок не имел значения. Сказав, что я построил заказную систему с NSB раньше, вот как я решил это сделать:

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

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

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

  • Добавьте номер версии во все поля, которые вы можете изменить с помощью версии.
  • обновляйте поле только в том случае, если номер версии в сообщении >= последняя версия в БД

Это имеет кучу преимуществ.

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

Но у него есть следующие недостатки:

  • Добавлена ​​сложность в БД
  • В конечном итоге он непротиворечив, если вы посмотрите на базу данных, она может содержать только некоторые изменения, внесенные пользователем.
  • Если ошибки rev2 и rev3 обрабатываются правильно, некоторые пользовательские правки не будут присутствовать, но некоторые будут
person Not loved    schedule 07.09.2013
comment
На ваш взгляд, насколько важно, чтобы NServiceBus обеспечивал поддержку на уровне фреймворка для этого сценария? - person Udi Dahan; 07.09.2013
comment
@UdiDahan в нашем сценарии, я думаю, мы сделали ошибку, потребовав порядка. Если бы мне пришлось сделать это снова, я бы сделал что-то похожее на то, что я описал выше. Я думаю, что лучший вариант - поддерживать любой порядок в обработчиках, а не навязывать порядок во фреймворке, но это только мое мнение. - person Not loved; 08.09.2013
comment
@LukeMcGregor Спасибо - я так и думал. - person Udi Dahan; 08.09.2013
comment
Спасибо за помощь. Я решил использовать модифицированную версию варианта 2 из моего вопроса - таким образом, порядок сообщений не зависит. - person maddog; 09.09.2013
comment
@JoelDSouza, это здорово, я действительно думаю, что это правильный путь, хотя его немного сложнее реализовать, он даст вам самый низкий подход к обслуживанию в долгосрочной перспективе. - person Not loved; 09.09.2013