Шаблон конкурирующих потребителей

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

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

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

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

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

Решение

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

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

Замечание

Несколько потребителей получают эти сообщения, но шаблон конкурирующих потребителей отличается от шаблонаPublisher-Subscriber. В шаблоне конкурирующих потребителей один потребитель получает каждое сообщение для обработки. В шаблоне Publisher-Subscriber все потребители получают каждое сообщение.

Это решение имеет следующие преимущества:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Задачи являются независимыми и могут выполняться параллельно.

• Объем работы весьма переменный и требует масштабируемого решения.

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

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

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

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

• Задачи должны выполняться в определенной последовательности.

Замечание

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

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

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

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

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

Пример

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

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

Слева стрелка указывает от приложения к разделу сообщения, включающему Service Bus. Стрелка с меткой «точки отказа» указывает из этого раздела в очередь непринятых сообщений. Другая строка из раздела сообщения разбивается на две стрелки, пронумерованные 1 и 2, указывающие на потребителей 1 и 2 соответственно.

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

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

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

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

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

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

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

• Шаблон выравнивания нагрузки на основе очередей: очередь сообщений может добавить устойчивость к системе. Устойчивость к нагрузке позволяет экземплярам служб обрабатывать разнообразные объемы запросов от экземпляров приложений. Очередь сообщений работает в качестве буфера, который выравнивает нагрузку. Шаблон балансировки нагрузки на основе очередей (Queue-based Load Leveling pattern) описывает этот сценарий более подробно.