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

Служебная шина Azure

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

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

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

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

Решение

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

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

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

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

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

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

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

Одна очередь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Message broker and queues: в примере используется Azure Service Bus в качестве брокера сообщений. Он использует две очереди Azure Service Bus, по одному для каждого приоритета сообщения (High и Low). Приложение (производитель) отправляет сообщения в правильную очередь на основе сообщения Priority.

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

Роль в примере архитектуры	Azure служба в примере	Имя в примере
Приложение	приложение Azure Functions	PriorityQueueSender (Отправитель PriorityQueue)
Брокер очередей сообщений	Azure Service Bus	< пространство имен служебной шины>
Очереди сообщений	очереди Azure Service Bus	< имена очередей>
Потребители	приложение Azure Functions	ОчередьСПриоритетомПотребительВысокий PriorityQueueConsumerLow

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

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

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

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

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

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

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

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

Решение

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

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

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

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

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

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

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

Одна очередь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Message broker and queues: в примере используется Azure Service Bus в качестве брокера сообщений. Он использует две очереди Azure Service Bus, по одному для каждого приоритета сообщения (High и Low). Приложение (производитель) отправляет сообщения в правильную очередь на основе сообщения Priority.

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

Роль в примере архитектуры	Azure служба в примере	Имя в примере
Приложение	приложение Azure Functions	PriorityQueueSender (Отправитель PriorityQueue)
Брокер очередей сообщений	Azure Service Bus	< пространство имен служебной шины>
Очереди сообщений	очереди Azure Service Bus	< имена очередей>
Потребители	приложение Azure Functions	ОчередьСПриоритетомПотребительВысокий PriorityQueueConsumerLow

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

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

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

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