Обработка набора связанных сообщений в определенном порядке без блокирования обработки других групп сообщений.
Контекст и проблема
Приложения часто должны обрабатывать последовательность сообщений в том порядке, в который они приходят, и по-прежнему могут масштабироваться для обработки повышенной нагрузки. В распределенной архитектуре обработка этих сообщений не является простой, так как работники могут масштабироваться независимо и часто извлекать сообщения независимо, используя шаблон конкурирующих потребителей.
Например, система отслеживания заказов получает реестр, содержащий заказы, и соответствующие операции с этими заказами. Эти операции могут быть для создания заказа, добавления транзакции в заказ, изменения предыдущей транзакции или удаления заказа. В этой системе операции должны выполняться в режиме первого выхода (FIFO), но только на уровне заказа. Однако начальная очередь получает реестр, содержащий транзакции для многих заказов, которые могут быть переплетированы.
Решение
Отправка связанных сообщений в категории в системе очередей и блокировка прослушивателей очередей и извлечение только из одной категории, одно сообщение за раз.
Вот как выглядит общий шаблон последовательного конвоя:
В очереди сообщения для разных категорий могут быть перемечены, как показано на следующей схеме:
Проблемы и рекомендации
При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.
- Категория или единица масштабирования. Какое свойство входящих сообщений можно масштабировать? В сценарии отслеживания заказов это свойство является идентификатором заказа.
- Пропускная способность. Какова целевая пропускная способность сообщения? Если это очень высоко, вам может потребоваться пересмотреть требования FIFO. Например, можно применить начальное или конечное сообщение, отсортировать по времени, а затем отправить пакет для обработки?
- Возможности службы. Разрешает ли выбор шины сообщений для однократной обработки сообщений в очереди или категории очереди?
- Эволюционируемость. Как добавить новую категорию сообщения в систему? Например, предположим, что система реестра, описанная выше, является конкретным клиентом. Если вам нужно подключить нового клиента, можно ли использовать набор процессоров реестра, которые распределяют работу по идентификатору клиента?
- Возможно, потребители могут получать сообщение вне порядка из-за переменной сетевой задержки при отправке сообщений. Рекомендуется использовать порядковые номера для проверки порядка. Вы также можете включить специальный флаг "конец последовательности" в последнее сообщение транзакции. Технологии потоковой обработки, такие как Spark или Azure Stream Analytics, могут обрабатывать сообщения в течение определенного периода времени.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
- У вас есть сообщения, которые прибывают в порядке и должны обрабатываться в том же порядке.
- Поступающие сообщения могут быть "классифицированы" таким образом, чтобы категория стала единицей масштабирования для системы.
Этот шаблон может не подходить для следующих целей:
- Сценарии с чрезвычайно высокой пропускной способностью (миллионы сообщений или секунды), так как требование FIFO ограничивает масштабирование, которое можно сделать системой.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон последовательного конвоя можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Этот шаблон может исключить условия гонки, которые трудно устранять неполадки, обработку спорных сообщений или другие обходные пути для решения неправильно упорядоченных сообщений, которые могут привести к сбоям. - Критически важные потоки RE:02 - Задания RE:07 Фоновые задания |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
В Azure этот шаблон можно реализовать с помощью сеансов сообщений Служебная шина Azure. Для потребителей можно использовать Logic Apps с соединителем служебная шина с помощью соединителя блокировки служебная шина или Функции Azure с триггером служебная шина.
В предыдущем примере отслеживания заказов обработайте каждое сообщение реестра в том порядке, в котором оно получено, и отправьте каждую транзакцию в другую очередь, в которой для категории задан идентификатор заказа. Транзакция никогда не будет охватывать несколько заказов в этом сценарии, поэтому потребители обрабатывают каждую категорию параллельно, но FIFO в категории.
Выдумка обработчика выгружает сообщения путем отмены пакетной обработки содержимого каждого сообщения в первой очереди:
Обработчик реестра заботится о следующих элементах:
- Переход к реестру по одной транзакции за раз.
- Задание идентификатора сеанса сообщения в соответствии с идентификатором заказа.
- Отправка каждой транзакции реестра в вторичную очередь с идентификатором сеанса, заданным идентификатором заказа.
Потребители прослушивают вторичную очередь, в которой обрабатываются все сообщения с соответствующими идентификаторами порядка в порядке из очереди. Потребители используют режим просмотра блокировки .
При рассмотрении масштабируемости очередь реестра является основным узким местом. Различные транзакции, размещенные в реестре, могут ссылаться на один и тот же идентификатор заказа. Однако сообщения могут раздувать после реестра количество заказов в бессерверной среде.
Следующие шаги
К реализации этого шаблона могут относиться следующие сведения: