Обнаружение и удаление потерянных очередей, тем или подписок в служебной шине Azure

В этом сценарии вы хотите, чтобы Очередь / Подписки были «динамическими» по своей природе. Они будут создаваться и удаляться в зависимости от использования, в отличие от текущей явной модели предоставления для этих сущностей. Служебная шина предоставляет вам API-интерфейсы для выполнения операций создания / удаления, чтобы вы могли соответствующим образом подключать их к событиям роли OnStart / OnStop. Если по какой-либо причине эти операции завершатся неудачно, то потерянные сущности будут существовать. Опять же, вы можете запустить для них операцию очистки на основе некоторого уникального идентификатора для имени сущностей. Пример этого можно увидеть здесь: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/

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

Очереди служебной шины создаются с использованием инфраструктуры «обмена сообщениями через посредника», предназначенной для интеграции приложений или компонентов приложений, которые могут охватывать несколько протоколов связи, контрактов данных, доменов доверия и / или сетевых сред. Это позволяет механизму надежно общаться с помощью надежного обмена сообщениями.

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

Я действительно пытаюсь сказать, что вы не получите потерянную очередь, вы можете получить отравленные сообщения, которые вам нужно будет обработать, это сообщение в блоге дает очень подробную информацию о: очередях служебной шины, их емкости и квотах, которые может помочь вам лучше понять http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx

Re: Управление очередью, вы можете сделать это через Visual Studio (1.7 SDK и инструменты) или есть отличный инструмент под названием Service Bus Explorer, который упростит вашу жизнь для управления очередью: http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a

* Обратите внимание, что максимальное количество очередей по умолчанию составляет 10 000 (на пространство имен службы, это может быть увеличено с помощью обращения в службу поддержки).

Как упомянул Абхишек Лай, возможность обнаружения сирот не поддерживается.

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

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

Служебная шина предоставляет функциональные возможности, которые помогут вам корректно восстановиться после ошибок в вашем приложении или трудностей с обработкой сообщения. Если приложение-получатель не может обработать сообщение по какой-либо причине, оно может вызвать метод Abandon для полученного сообщения (вместо метода Complete). Это заставит служебную шину разблокировать сообщение в очереди и сделать его доступным для повторного приема либо тем же приложением-потребителем, либо другим приложением-потребителем.

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

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

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

Я проверил это, создав несколько очередей, а затем завершив работу приложений. Эти очереди еще долгое время оставались на машине.

Вся суть очереди заключается в том, чтобы гарантировать доставку сообщений слабо разделенных приложений. Думайте об очереди как о самостоятельном объекте или приложении с высокой доступностью (SLA), размещенном в Azure, ваш производитель / потребители могут умереть / перезапуститься, и очередь будет активна в Azure. * Заметьте, я немного запутался в вашей формулировке относительно: «все еще на машине долгое время спустя», очередь на самом деле не находится на вашем компьютере, она находится в Azure в назначенном пространстве имен служебной шины. Вы можете просматривать очереди и управлять ими с помощью инструментов, которые я указал в предыдущем ответе.

Как мы можем обнаруживать и удалять эти очереди, поскольку они будут учитываться при учете ограничений Azure и т. Д.

Как указано выше, максимальное количество очередей по умолчанию составляет 10 000 (для каждого пространства имен службы это может быть увеличено с помощью обращения в службу поддержки), управление очередью может осуществляться с помощью инструментов, указанных в другом ответе. Вам следует стремиться к удалению очереди только тогда, когда у вас больше нет производителя / потребителей, желающих писать им (т.е. никогда больше). Конечно, вы можете создавать и удалять очереди в своих приложениях производителя / потребителя через namespaceManager.QueueExists, дополнительная информация здесь Как использовать очереди служебной шины

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

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