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

Question

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

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

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

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

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

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

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

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

Как мне решить эту проблему?

РЕДАКТИРОВАТЬ:

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

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

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

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

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

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

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

Answer 1

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

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

Проблема наличия одного процесса в отказоустойчивой инфраструктуре может быть решена с помощью блокировки. Вы можете использовать хранилище BLOB-объектов в качестве блокировки, как показано в сообщении BLOB-объекта 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, то рабочие могут использовать эту очередь для распределенной обработки запросов.Когда один рабочий экземпляр читает сообщение из очереди, это сообщение больше не отображается ни для каких других рабочих экземпляров в течение заданного промежутка времени (который можно увеличить путем периодического возобновления аренды сообщения).Это не позволяет двум работникам обрабатывать одни и те же сообщения.

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

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