Служебная шина Azure: как добиться согласованности при выходе из строя подписчика

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

Имеется ли в служебной шине Azure какое-либо решение «источника событий» для воспроизведения моих событий? Я понимаю, что в концентраторах событий Azure есть эта функция, с помощью которой я могу хранить события в режиме только добавления в хранилище BLOB-объектов Azure. Однако единственное, что я обнаружил для служебной шины Azure, - это очередь недоставленных сообщений, и я понимаю, что она используется только тогда, когда ни один подписчик не может обработать событие.

Это что-то, что мне придется построить самому?


person Josh L    schedule 01.11.2019    source источник
comment
Подписчики должны фиксировать сообщение только в том случае, если оно было успешно обработано. Таким образом, если подписчик умирает, сообщения будут там, когда он вернется. Сервисная шина имеет лучшие гарантии надежности, чем концентраторы событий, поэтому лучше подходит для транзакционных сообщений.   -  person StuartLC    schedule 01.11.2019
comment
Хорошо, простите за невежество, я смотрю на это с очень высокого уровня. Допустим, у меня есть два подписчика, SubcriberA может успешно получить событие, SubscriberB находится в автономном режиме и не работает. Остается ли событие в очереди до тех пор, пока SubscriberB не вернется в режим онлайн?   -  person Josh L    schedule 01.11.2019
comment
Да, в отличие от концентраторов событий, на служебной шине каждая подписка получает свою собственную копию каждого сообщения, отвечающего критериям подписки. Imo SB не станет хорошим хранилищем событий с точки зрения поиска событий. Концентраторы событий лучше подходят для ES, но учтите, что у них ограниченное время хранения. Сохранение, например, очередей хранилища все еще может быть необходимо для долгосрочного воспроизведения.   -  person StuartLC    schedule 01.11.2019


Ответы (1)


Все события, хранящиеся в подписке, будут доставляться после того, как потребитель будет запущен и работает, если в подписке не установлено DefaultMessageTimeToLive (TTL) для очистки сообщений.

person Sean Feldman    schedule 01.11.2019
comment
Я не могу найти в документации по служебной шине Azure ничего, подтверждающее это утверждение? Единственное, что я вижу, - это очередь недоставленных сообщений, в которой говорится: Цель очереди недоставленных сообщений - хранить сообщения, которые не могут быть доставлены ни одному получателю, или сообщения, которые не могут быть обработаны. - person Josh L; 07.11.2019
comment
Чтобы поддержать это утверждение? Я потерял тебя. Подписка - это, по сути, очередь. Вы ищете документацию, в которой говорилось бы, что в очереди будут храниться ваши сообщения? В этом вся идея организации очереди и обмена сообщениями ???? Как бы то ни было, проверка проста. Создайте тему с подпиской, опубликуйте сообщение и посмотрите, сохраняет ли подписка без каких-либо потребителей сообщение или нет. Ваше здоровье. - person Sean Feldman; 08.11.2019
comment
Дополнительная информация - основные возможности: docs.microsoft.com/en-us/azure/service-bus-messaging/ Очереди служебной шины поддерживают поддержку атомарных операций. - person Mike Ubezzi MSFT; 18.11.2019