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

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

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

Рабочие нагрузки часто нуждаются в управлении и обработке задач с различными уровнями важности и срочности. Некоторые задачи требуют непосредственного внимания, а другие могут ждать. Неисполнение задач с высоким приоритетом может повлиять на взаимодействие с пользователем и соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания).

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

Решение

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

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

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

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

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

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

• Несколько очередей: отдельные очереди используются для каждого приоритета сообщения.

Одна очередь

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

Рисунок 1. Архитектура одной очереди и одного пула потребителей

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

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

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

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

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

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

Рисунок 2. Архитектура нескольких очередей и нескольких пулов потребителей.

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

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

Используйте один пул потребителей для:

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

Рисунок 3. Архитектура нескольких очередей и одного пула потребителей.

Рекомендации по шаблону очереди приоритета

При выборе способа реализации шаблона очереди приоритета рекомендуется учитывать следующие рекомендации.

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

• Четко определите приоритеты. Установите отдельные и четкие уровни приоритета, относящиеся к вашему решению. Например, для сообщения с высоким приоритетом может потребоваться обработка в течение 10 секунд. Определите требования для обработки элементов с высоким приоритетом и выделите необходимые ресурсы соответствующим образом.

• Динамическое изменение пулов потребителей. Масштабируйте размер пулов потребителей на основе длины очереди, которую они обслуживают.

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

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

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

Рекомендации по нескольким очередям

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

• Свести к минимуму затраты. Обработка критически важных задач немедленно с доступными потребителями. Планирование менее критически важных фоновых задач во время меньшей нагрузки.

Рекомендации по одному пулу потребителей

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

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

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

Архитектор должен оценить, как шаблон очереди приоритета может решать цели и принципы, описанные в основных принципах Платформы Azure Well-Architected Framework. Например:

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

Пример шаблона очереди приоритета

В следующем примере в GitHub демонстрируется реализация шаблона очередей приоритетов с помощью Служебная шина Azure.

Рисунок 4. Архитектура примера PriorityQueue в GitHub

Ниже приведен обзор архитектуры:

• Приложение (производитель): в примере есть приложение (PriorityQueueSender), которое создает сообщения и назначает пользовательское свойство, вызываемое Priority в каждом сообщении. Priority имеет значение High или Low.

• Брокер сообщений и очереди: в примере используется Служебная шина Azure в качестве брокера сообщений. В нем используются две очереди Служебная шина Azure, по одному для каждого приоритета сообщения (HighиLow). Приложение (производитель) отправляет сообщения в правильную очередь на основе сообщения Priority.

• Несколько пулов потребителей: в примере используется несколько пулов потребителей (PriorityQueueConsumerHigh и PriorityQueueConsumerLow) выделенных для чтения сообщений из каждой очереди.

Связанные ресурсы

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

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

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