В частности, Sagas NServiceBus: параллельный доступ к данным Saga сохраняется в хранилище таблиц Azure

Этот вопрос касается одновременного доступа к данным саги, когда данные саги сохраняются в хранилище таблиц Azure. Это также справочная информация, найденная в документации Particular: http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency

Мы заметили, что в одной и той же саге, выполняющей обработчики одновременно, модификации к саговым данным, по-видимому, работают в сценарии "последний, кто опубликовал изменения в выигрышах хранения таблицы Azure". Это предполагаемое поведение при использовании NSB в сочетании с хранилищем таблиц Azure в качестве уровня сохраняемости данных Saga?

Пример:

  1. Целочисленное свойство в Saga Data, предположим, что оно в настоящее время = 5
  2. 5 команд обрабатываются 5 экземплярами одного и того же обработчика в этой саге
  3. Каждый обработчик команд уменьшает целочисленное свойство в данных саги
  4. Окончательное значение свойства integer в данных саги может фактически равняться 4 после обработки этих 5 сообщений - если каждое сообщение обрабатывается новым экземпляром саги, возможно, на разных серверах, каждое из которых имеет копию данных саги, указывающих, что свойство integer равно 5, уменьшите его до 4 и отправьте обратно. То, что я только что описал, было чрезвычайно параллельным примером, однако вполне вероятно, что целое число будет больше 0, если какое-либо из 5 сообщений было обработано одновременно, единственный раз, когда свойство целочисленного значения данных saga достигает 0, это когда 5 команд выполнили серийно.

Кроме того, поскольку хранилище таблиц Azure поддерживает оптимистичный параллелизм, возможно ли разрешить использование этой функции для хранения таблиц так же, как она включена для RavenDB, когда Raven используется в качестве технологии персистентности?

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

Источник

2 ответа

Решение

После работы с определенной поддержкой - описанные выше симптомы оказались дефектом в NServiceBus.Azure. Эта проблема была исправлена ​​Particular в NServiceBus.Azure 5.3.11 и 6.2+. Я могу лично подтвердить, что обновление до 5.3.11 решило наши проблемы.

Для справки, явным признаком проявления этой проблемы является следующее исключение, которое выдается и не обрабатывается.

Не удалось обработать сообщение Microsoft.WindowsAzure.Storage.StorageException: непредвиденный код ответа для операции: 0

В подробностях исключения будет указано, что "UpdateConditionNotSatisfied" относится к проверке оптимистичного параллелизма.

Спасибо Иву Гоелевену и Шону Фельдману из Particular за диагностику и решение этой проблемы.

Источник

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

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

PS: в прошлом году мы решили проблему, которая звучит очень похоже на эту https://github.com/Particular/NServiceBus.Azure/issues/124 она была решена в NServiceBus.Azure 5.2 и выше.

Источник
Другие вопросы по тегам