Как создать" отдельную " очередь в Azure?
У меня есть следующая теоретическая задача.
Я хотел бы иметь возможность создавать несколько экземпляров каждой роли в моем приложении Azure. По крайней мере 2, чтобы убедиться, что он работает 24/7 (или почти 24/7).
Это легко для клиентских интерфейсов и ролей, которые прослушивают данные.
Это также легко для рабочих ролей, которые обрабатывают данные и сохраняют результаты в больших двоичных объектах / табличном хранилище, предполагая, что каждая рабочая роль обрабатывает свой собственный набор данных для создания единого результата.
Но я ... возникли проблемы с "серединой" этого приложения.
В простейшем случае, если бы я мог создать "отдельную" очередь хранилища Azure (нет двух одинаковых сообщений), это было бы легко. Но насколько я знаю, это невозможно сделать, тем более что вы можете загрузить только 32 сообщения одновременно.
Итак, мне нужна какая-то роль контролера... Я думаю. Эта роль гарантирует, что рабочие роли не будут мешать друг другу.
Но это означает, что роль контроллера не может имейте больше чем один экземпляр!
Как мне подойти к этой проблеме?
Правка:
Я вижу, что, возможно, дал слишком мало информации о моей проблеме.
Я знаю, как работают очереди Azure; я знаю, что после удаления сообщения из очереди оно будет недоступно для других ролей в течение определенного периода времени или до тех пор, пока оно не будет удалено.
Дело в том, что я не могу просто заполнить очередь случайными, уникальными данными, такими как GUID.Вот более приземленное объяснение проблема.
- Роли слушателей прослушивают клиентские данные и помещают их в базовую таблицу, а затем уведомляют через очередь, что определенная часть этой таблицы была изменена.
Роли слушателей могут сообщать, что одна и та же часть таблицы была изменена несколько раз - они не отслеживают, что происходит с очередью, и что уже находится в ней, поэтому они просто отправляют сообщения в виде "Эй, я изменил этот бит для этого клиента" (например).
- рабочие создание или обновление определенных файлов (в основном больших двоичных объектов) на основе сообщений, предоставляемых слушателями. В настоящее время существует один работник, который загружает всю очередь, проверяет наличие отдельных сообщений, а затем обновляет все файлы по мере необходимости. Добавление второго работника вызывает проблемы: поскольку очередь обычно не содержит различных значений, два работника могут начать работать над одним и тем же выходным файлом и прерывать друг друга.
Таким образом, я ищу очередь, которая отличается, или по крайней мере предоставляет возможность проверить, не было ли в нем уже помещено определенное сообщение.
Если служебная Шина-единственный путь, то так тому и быть, но было бы неплохо сделать решение как можно более простым. ;)
3 ответа:
Очереди служебной шины имеют понятие уникальных сообщений (что может быть тем, что вы подразумеваете под различными). Здесь есть хорошее сравнение между двумя типами очередей:
Проблема наличия одного процесса в устойчивой инфраструктуре может быть решена с помощью блокировки. Вы можете использовать хранилище blob-объектов в качестве блокировки, как показано на примере blob-объекта SmartX сообщение:
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/
But as far as I know, this cannot be done, especially since you can download only 32 messages at a time.Это не так. При чтении элементов из очереди, элементы не появляются в очереди в течение заданного времени (настраивается). После завершения обработки вы можете удалить сообщение из очереди. Генерация идентификатора очереди может быть уникальным и самым простым и прямым способом использования GUID. Вы можете использовать это для разработки системы, которая считывает уникальные ключевые элементы.
Конечная причина, по которой кто-то использует очередь, заключается в том, чтобы точно решить сложность нескольких рабочих ролей. ввод из очереди без каких-либо проблем.
Если роли переднего плана регистрируют запросы в очереди хранилища Azure, то работники могут использовать эту очередь для распределенной обработки запросов. Когда один экземпляр worker считывает сообщение из очереди, это сообщение больше не видно ни одному другому экземпляру worker в течение заданного периода времени (который можно увеличить, периодически обновляя арендную плату для сообщения). Это не позволяет двум работникам одновременно обрабатывать одни и те же сообщения.
Альтернативно, вы можете использовать шаблон для самостоятельного выбора экземпляра контроллера. Этот шаблон говорит, что процесс для контроллера существует во всех экземплярах ролей. Когда экземпляры запускаются, процесс сначала пытается получить монопольную блокировку объекта, например, арендуя объект blob-объекта хранилища Azure. Первый, кто получает аренду, становится "контроллером", остальные ложатся спать, чтобы ждать и периодически проверять, доступен ли blob для аренды снова. Это позволяет другому экземпляру взять на себя роль контроллер, если первое становится недоступным (это становится самоисцелением в некотором смысле).
Я думаю, что первый подход будет моим первым выбором, так как он не требует много сложного кодирования. Но в зависимости от того, что вы пытаетесь сделать, второй вариант также может быть достойным решением, если вы готовы инвестировать время.