Как создать «отличную» очередь в Azure?

Question

У меня есть следующая теоретическая проблема.

Я хотел бы иметь возможность создавать несколько экземпляров каждой роли в приложении Azure. По крайней мере, 2, чтобы убедиться, что он работает 24/7 (или почти 24/7).

Это легко для клиентских интерфейсов и ролей, которые прослушивают данные.

Это также легко для рабочих ролей, которые обрабатывают данные и сохраняют результаты в blobs/table-storage при условии, что каждая рабочая роль обрабатывает собственный набор данных для создания одного результата.

Но у меня возникла проблема с «средой» этого приложения.

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

Итак, мне нужна роль контроллера. Думаю. Эта роль обеспечит, чтобы рабочие роли не мешали друг другу.

НО, это означает, что роль контроллера не может иметь более одного экземпляра!

Как мне подойти к этой проблеме?

EDIT:

Я вижу, что, возможно, дал слишком мало информации о моей проблеме.

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

Дело в том, что я не могу просто заполнить очередь случайными уникальными данными, такими как GUID.

Вот более подробное объяснение проблемы.

• Роли прослушивания прослушивают данные клиента и помещают эти данные в базовую таблицу, а затем уведомляют через очередь, что определенная часть этой таблицы была изменена.
• Роли слушателя могут сообщать, что одна и та же часть таблицы была изменена несколько раз - они не отслеживают, что происходит с очередью, и что уже в ней, поэтому они просто отправляют сообщения по строкам «эй» , Я изменил этот бит для этого клиента »(например).
• Рабочие создают или обновляют определенные файлы (в основном капли) на основе сообщений, предоставляемых слушателями. В настоящее время есть один рабочий, который загружает всю очередь, проверяет отдельные сообщения и затем обновляет все файлы по мере необходимости. Добавление второго работника вызывает проблемы: поскольку очередь обычно НЕ содержит отдельных значений, два рабочих могут начать работать над одним и тем же выходным файлом и прервать друг друга.

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

Если служебная шина - единственный способ пойти, то пусть будет так, но было бы неплохо сделать решение максимально простым.;)

Answer 1

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

http://preps2.wordpress.com/2011/09/17/comparison-of-windows-azure-storage-queues-and-service-bus-queues/

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

http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases

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

http://coderead.wordpress.com/2012/03/23/three-tier-architecture-in-the-cloud/

Answer 2

But as far as I know, this cannot be done, especially since you can download only 32 messages at a time.

Это не так. Когда вы читаете элементы из очереди, элементы не отображаются в очереди за определенное количество времени (настраивается). Как только обработка будет выполнена, вы можете удалить сообщение. Генерация идентификатора очереди может быть уникальной & Простейший & прямой способ использования GUID. Вы можете использовать это для разработки системы, которая считывает уникальные ключевые элементы.

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

Answer 3

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

В качестве альтернативы вы можете использовать шаблон для самостоятельного выбора экземпляра контроллера. Этот шаблон говорит о том, что процесс для контроллера существует во всех экземплярах ролей. Когда экземпляры запускаются, процесс сначала пытается получить эксклюзивную блокировку объекта, например, лизинг объекта blob Azure Storage. Первым, кто получит аренду, становится «контроллер», остальные ждут спать и периодически проверяют, можно ли снова использовать блобчатку для аренды. Это позволяет другому экземпляру взять на себя управление, если первый становится недоступным (он становится самоисцелением в манере речи).

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