Как масштабировать рабочую роль Azure, если поток занят ожиданием?

Я надеюсь, что ниже объясняется моя проблема.

У меня есть рабочая роль, которая работает в цикле while (true). Этот рабочий берет сообщения из очереди и обрабатывает их. Он никогда не заканчивается, просто продолжает проверять очередь и обрабатывать сообщения.

Это работает до тех пор, пока я не получу сообщение, которое требует, чтобы я сделал что-то, что требует времени. Примером может быть запрос информации от службы. Предположим, что этот запрос занимает 10 секунд. Теперь моя рабочая роль находится в середине цикла while, ожидая этого ответа. Тем временем очередь сообщений заполняется.

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

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

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

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

У этой рабочей роли теперь не будет ситуации, когда потоки застревают в ожидании чего-то.

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

Поэтому мне нужно БОЛЬШЕ обработчиков очередей, которые должны быть созданы путем порождения экземпляров моего обработчика очередей в зависимости от того, насколько занята моя очередь. Поэтому, когда в очереди много элементов, Azure создаст новый экземпляр, чтобы помочь мне их обработать.

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

Имеет ли смысл мое решение или есть альтернативы?


azure c# task-parallel-library azure-worker-roles
person LivingOnACloud    schedule 24.01.2015    source источник
comment
Асинхронный ввод-вывод здесь не имеет значения, поскольку ваша степень параллелизма довольно мала (например, десятки параллельных сообщений). Застревание нитей не проблема, если их достаточно.   -  person usr    schedule 24.01.2015
comment
Я не вижу, в чем проблема. Разве вы не можете просто создать N потоков/асинхронных задач для извлечения из очереди? Есть ли в этом конкретная проблема? Загрузка процессора не кажется вам проблемой. Если загрузка ЦП не является проблемой, масштабирование до большего числа ЦП не требуется.   -  person usr    schedule 24.01.2015
comment
Я думаю, что: A. Вы должны опубликовать свой код B. Измерить, измерить, измерить.   -  person Yuval Itzchakov    schedule 24.01.2015
comment
@YuvalItzchakov невозможно измерить, хорошо ли спроектирована и стабильна система. Кажется, это вопрос архитектуры.   -  person usr    schedule 24.01.2015
comment
@usr Верно. Но я думаю о том, чтобы TPL запускал несколько десятков обработчиков очередей на моей одноядерной машине, поэтому, если один вернется на длительный асинхронный вызов, другие продолжат работу. Я не особо задумывался над этой идеей, потому что это не решение, и не был уверен, что она сработает.   -  person LivingOnACloud    schedule 24.01.2015
comment
Почему это не решение? Я до сих пор не понимаю, почему этот простой подход N thread/task не работает во всех отношениях. Я могу ответить вам, только если я понимаю вашу проблему.   -  person usr    schedule 24.01.2015
comment
@usr Запуск архитектуры с N потоков и измерение узких мест - единственный способ понять, где ему на самом деле нужно пройти лишнюю милю.   -  person Yuval Itzchakov    schedule 24.01.2015
comment
@YuvalItzchakov Я согласен. Пока вопрос без ответа, потому что не видно конкретной проблемы. Закрытие.   -  person usr    schedule 24.01.2015

Ответы (1)


arrow_upward
2
arrow_downward

Посмотрите на причину, по которой вам нужно масштабироваться

Предположим, что этот запрос занимает 10 секунд. Теперь моя рабочая роль находится в середине цикла while, ожидая этого ответа. Тем временем очередь сообщений заполняется.

Проблема не столько в том, что рабочий процесс занимает много времени, сколько в том, что резервируется очередь — именно поэтому Azure предлагает параметры масштабирования, в том числе размер очереди.

Кроме того, если ваши службы интенсивно используют ЦП, то масштабирование только распространит проблему на несколько экземпляров — это только вопрос времени, когда вы столкнетесь с одним и тем же узким местом.

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

person James    schedule 24.01.2015