Шаблон приоритетной очереди

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

Контекст и проблема

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

Для эффективной обработки задач на основе их приоритета рабочие нагрузки нуждаются в механизме обработки и выполнения задач соответствующим образом. По умолчанию большинство нагрузок обрабатывают задачи в том порядке, в котором они поступают, используя очередь по принципу «первым пришёл — первым обслужен» (FIFO). Этот подход не учитывает различные значения задач.

Решение

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

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

Существует два основных подхода к реализации шаблона очереди приоритета:

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

Одна очередь

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

Несколько очередей

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

Один пул потребителей

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

Используйте один пул потребителей по следующим причинам:

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

Несколько пулов потребителей

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

Используйте несколько пулов потребителей по следующим причинам:

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

Проблемы и рекомендации

Рассмотрим следующие моменты, когда вы решите, как реализовать этот шаблон:

Общие рекомендации

Четко определите приоритеты. Установите отдельные и четкие уровни приоритета, относящиеся к решению. Например, можно определить сообщения с высоким приоритетом в качестве тех, которые требуют обработки в течение 10 секунд. Определите требования потребителя для обработки элементов с высоким приоритетом и выделите необходимые ресурсы соответствующим образом.
Динамическое изменение пулов потребителей. Масштабируйте размер пулов потребителей на основе длины очереди, которую они обслуживают.
Следите за состоянием очереди. Отслеживайте глубину очереди, задержку обработки, количество доставки и пропускную способность, чтобы обнаруживать невыполненные операции и замедления, прежде чем они влияют на работу.
Используйте очереди недоставленных писем. Переместите подозрительные сообщения в очередь недоставленных писем после настраиваемого количества попыток доставки, чтобы одно плохое сообщение не блокирует путь приоритета.
Выделите приоритет уровням обслуживания. Реализуйте очереди приоритетов для удовлетворения бизнес-потребностей, требующих приоритета доступности или производительности. Например, клиенты с высоким приоритетом могут получать более высокий уровень сервиса, благодаря чему они получают более высокую производительность и доступность.
Рассмотрим низкоприоритетную обработку. Определите, следует ли обрабатывать все элементы с высоким приоритетом перед любыми элементами с более низким приоритетом. По возможности динамически увеличьте приоритет старых сообщений, чтобы обеспечить обработку низкоприоритетных сообщений.
Оптимизация и минимизация затрат. Обрабатывайте критически важные задачи немедленно с участием доступных потребителей. Планирование менее критически важных фоновых задач во время меньшей нагрузки.

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

Этот шаблон может быть не подходит, если:

Все рабочие элементы имеют аналогичную бизнес-важность, и строгая обработка FIFO является более важной, чем планирование на основе приоритетов.
Задачи имеют строгое упорядочение зависимостей между уровнями приоритета, а переупорядочение работы по приоритету может привести к несогласованным результатам или требовать сложной логики координации.

Проектирование рабочей нагрузки

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

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя.	Разделение элементов на основе приоритета бизнеса позволяет сосредоточить усилия по надежности на наиболее критически важных работах. - Критически важные потоки RE:02
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Разделение элементов на основе приоритета бизнеса позволяет сосредоточить усилия на производительности на наиболее чувствительных к времени работах. - PE:09 Критические потоки

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Example

Пример шаблона очереди приоритета в GitHub демонстрирует реализацию шаблона очереди приоритета, использующего Служебная шина Azure темы и подписки. В этом примере развертывается безопасная учетная запись хранения, ресурс Application Insights для мониторинга и пространство имен служебная шина для обеспечения связи между функциями отправителя и потребителя.

Развертывание включает три приложения-функции: одно в роли отправителя и два в роли потребителей. Приложения-потребители используют разное максимальное количество экземпляров для имитации приоритизации сообщений. Функция funcPriorityQueueConsumerHigh может масштабироваться до 200 экземпляров, а funcPriorityQueueConsumerLow функция ограничена 40 экземплярами. Все приложения-функции используют план потребления Flex и подключены к Application Insights для диагностики и мониторинга.

Назначения ролей обеспечивают безопасный доступ к служебная шина и хранилищу через управляемые идентификаторы. Все приложения-функции используют одну и ту же учетную запись хранения и ресурс Application Insights. Эта конфигурация централизирует наблюдаемость и ведение журнала.

На следующей схеме показана архитектура очереди приоритета:

На предыдущей схеме показано следующее.

Приложение (производитель). Приложение PriorityQueueSender создает сообщения, назначает каждому сообщению настраиваемое свойство приложения с именем Priority и задает для значения Priority значение High или Low.
Брокер сообщений и раздел. Брокер сообщений служебная шина отправляет сообщения в один раздел служебная шина с именемmessages. служебная шина использует фильтры SQL для маршрутизации каждого сообщения в высокоприоритетную или низкоприоритетную подписку на основе его Priority значения.
Несколько пулов потребителей. Пулы потребителей PriorityQueueConsumerHigh и PriorityQueueConsumerLow обрабатывают сообщения из подписок с высоким или низким приоритетом с помощью триггеров служебная шина в Функции Azure.

Роль в примере	Azure служба в примере	Имя в примере
Приложение (производитель)	приложение Функции Azure	PriorityQueueSender (Отправитель PriorityQueue)
Брокер сообщений	Служебная шина Azure	<пространство имен служебной шины>
Раздел сообщения	тема Служебная шина Azure	`messages`
Подписки на сообщения	подписки Служебная шина Azure	`highPriority` `lowPriority`
Потребители	приложение Функции Azure	ОчередьСПриоритетомПотребительВысокий PriorityQueueConsumerLow

Дальнейшие действия

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

При реализации этого шаблона могут быть полезны следующие шаблоны:

Шаблон выравнивания нагрузки на основе очереди: используйте очередь в качестве буфера между приёмом запросов и их обработкой. Используйте его с шаблоном очереди приоритета, если требуется защита от всплеска и дифференцированная обработка.
Шаблон "Конкурирующие потребители": реализуйте несколько потребителей, которые прослушивают одну и ту же очередь и параллельно обрабатывают задачи, чтобы увеличить пропускную способность. Только один потребитель обрабатывает каждое сообщение.
Шаблон ограничения нагрузки: реализуйте ограничение с помощью очередей для управления частотой запросов. Используйте обмен приоритетом для определения приоритета запросов от критически важных приложений или высокоценных клиентов по сравнению с менее важными.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-08-14