Как брокер сообщений гарантирует доставку сообщений

Kafka vs RabbitMQ: что нужно знать аналитику про брокеры сообщений

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

Особенности Apache Kafka

Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.

Подход к обмену сообщениями

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

После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.

Архитектура Kafka

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

Гарантия доставки сообщений и ее последствия

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

Почему же многие очереди сообщений не гарантирую порядок? И так ли он вообще важен — этот порядок доставки?

Почему многие системы очередей не гарантируют порядок доставки? Link to heading

Здесь потребуется договорится об обозначениях.

Для любых двух событий A и B запись A→B означает, что событие A происходит перед событием B . Людям знакомым с Java Memory Model эта запись должна быть известна как отношение happens-before.

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

Исходя из этого мы можем определить порядок доставки сообщений следующим образом. Для двух любых сообщений m1 и m2 для которых выполняется условие receive(m1)→receive(m2) (то есть брокер получил сначала сообщение m1 потом m2 ), если гарантируется что dispatch(m1)→dispatch(m2) , значит очередь сообщений гарантирует порядок доставки.

Тем не менее гарантия в отношении порядка доставки мало что дает. Даже если сообщения доставлены в порядке (in-order), consumer’ы могут обработать сообщения в порядке отличном от порядка доставки (out-of-order).

Как любит говорить один мой коллега: “Тому есть тысяча причин”. Машины на которых работают consumer’ы могут быть разной конфигурации: у них могут быть разные процессоры, разный объем памяти, разная по производительности подсистема I/O. Но даже если они идентичны, у вас нет контроля над детерминизмом cpu и I/O scheduler’ов. Любая машина может отказать или начать медленно работать из-за большого количества pagefault’ов и т.д. Все это говорит о том, что порядок доставки сообщений не имеет ничего общего с порядком их обработки. А ведь именно порядок обработки, а не доставки должен интересовать нас в первую очередь.

Порядок обработки сообщений мы можем определить следующим образом. Для двух любых сообщений m1 и m2 для которых выполняется условие receive(m1)→receive(m2) , если гарантируется что ack(m1)→ack(m2) , значит очередь сообщений гарантирует порядок обработки.

Но соблюсти это правило очередь сообщений может только одним способом. Путем форсирования порядка ack(m1)→dispatch(m2) . Другими словами, брокер не должен отправлять следующее сообщение пока предыдущее не будет обработано. Это подразумевает следующую картину.

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

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

А важен ли порядок порядок обработки? Link to heading

Иногда да. Есть ситуации когда порядок обработки очень важен. Предыдущая заметка иллюстрирует один из таких случаев. Но вы должны понимать, что любой порядок в web-приложении является имитацией. В любом web-приложении клиенты посылают запросы параллельно. Эти запросы параллельно идут по сети, параллельно обрабатываются frontend’ами, параллельно идут на backend’ы и так же параллельно ответы идут обратно к пользователям.

Место где порядок обработки начинает проявляться — это реляционная база данных. Если два потока в транзакции модифицируют одни и те же кортежи, база данных останавливает выполнение одного из потоков до тех пор пока другой не завершит свою работу. База данных линеаризует выполнение нескольких потоков таким образом, что в системе появляется порядок обработки. Но вместе с появлением порядка обработки испаряется пропускная способность. К тому же тот порядок который навязывает база данных может не совпадать с порядком поступления запросов на frontend. Для двух любых запросов req1 и req2 связанных порядком receive(req1)→receive(req2) соблюдение правила transaction(req1)→transaction(req2) не гарантируется.

В свою очередь, это означает что сложность, которая присуща решению продемонстрированному в предыдущей заметке, не является сложностью присущей асинхронным системам обработки сообщений. Это сложность присущая web-приложениям в целом. И даже если бы вы исключили MQ-систему из транка обработки и, скажем, посылали бы сообщения через SOAP или напрямую писали в базу данных, вам все равно пришлось бы реализовывать те же механизмы, чтобы обеспечить сохранность данных. Любое web-приложение — это конкурентная система в природе которой порядок обработки запросов отсутствует.

Некоторых людей такая ситуация не устраивает. Отчасти являясь идеалистами (что особенно характерно для программистов) они не могут ужиться с мыслью, что те или иные процессы протекают стохастично и не имеют порядка в своей природе. Попытки навязать этот порядок обрекают web-приложение на деградацию пропускной способности. Вы можете наблюдать этот синдром повсюду — начиная от многопоточного программировния и использования mutex’ов до баз данных и протоколов XA-транзакций. В свое время Dan Pritchett написал об этом отличное эссе — “Chaotic Perspectives”.

Если вы web-программист, то я вас поздравляю. Судьба сделала вам подарок. В других отраслях программистам приходится прилагать титанические усилия для распараллеливания задач. У вас же большая часть процессов протекает и так параллельно. Все что вам надо, — смирится с мыслью, что порядок обработки запросов в системе не детерминистичен. С этим бессмысленно бороться, этим надо уметь пользоваться.

Apache Kafka и RabbitMQ: семантика и гарантия доставки сообщений

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

И RabbitMQ, и Kafka предлагают надёжные гарантии доставки сообщений. Обе платформы предлагают гарантии по принципам “как максимум однократная доставка” и “как минимум однократная доставка”, но вот с принципом “строго однократной доставки” гарантии Kafka действуют по очень ограниченному сценарию.

Сперва разберёмся, что означают эти гарантии:

• At-most-once delivery (“как максимум однократная доставка”). Это значит, что сообщение не может быть доставлено больше одного раза. При этом сообщение может быть потеряно.
• At-least-once delivery (“как минимум однократная доставка”). Это значит, что сообщение никогда не будет потеряно. При этом сообщение может быть доставлено более одного раза.
• Exactly-once delivery (“строго однократная доставка”). Святой грааль систем сообщений. Все сообщения доставляются строго единожды.

Второе. Обсуждая вопрос обработки сообщений, мы подходим к теме частичных отказов, являющейся головной болью для разработчиков. В процессе обработки сообщения присутствует несколько этапов. Он состоит из сеансов связи между приложением и системой сообщений в начале и в конце и работы самого приложения с данными в середине. Сценарии частичных отказов в работе приложения должны обрабатываться самим приложением. Если выполняемые операции полностью транзакционны и результаты формулируются по принципу “всё или ничего”, частичных сбоев в логике приложения удаётся избежать. Но нередко многие этапы включают в себя с взаимодействие с другими системами, где транзакционность невозможна. Если мы включаем во взаимодействие взаимосвязи между системами обмена сообщениями, приложениями, кэшем и базой данных, можем ли мы гарантировать обработку по принципу “строго единожды”? Ответ — “нет”.

Стратегия “строго единожды” ограничена сценарием, по которому единственным получателем обработанных сообщений является сама платформа обмена сообщениями, и сама эта платформа обеспечивает полноценные транзакции. По этому ограниченному сценарию можно обрабатывать сообщения, писать их, отправлять сигналы о том, что они обработаны в рамках транзакции, производимой по принципу “всё или ничего”. Это предусмотрено библиотекой Kafka Streams.

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

Сквозное оповещение

Что не представлено ни в каких устройствах всех систем обмена сообщениями, с которыми я работал, так это сквозное подтверждение. Если учесть, что в RabbitMQ сообщение может быть поставлено в несколько очередей, сквозное оповещение не имеет смысла. На Kafka, аналогично, несколько разных групп получателей могут считывать информацию одновременно из одного топика. По моему опыту, сквозное оповещение — это то, о чём чаще всего просят люди, плохо знакомые с концепцией передачи сообщений. В таких случаях лучше сразу объяснять, что это невозможно.

Цепочка ответственности

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

Порядок передачи сообщений

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

Если коротко, то и RabbitMQ, и Kafka предоставляют гарантию порядка простой очерёдности (first in first out, FIFO). RabbitMQ поддерживает такой порядок на уровне очереди, а Kafka — на уровне распределения на сегменты. Последствия таких проектных решений были рассмотрены в предыдущих статьях.

Гарантии доставки в RabbitMQ

Гарантии доставки обеспечиваются:

• надежностью сообщений — они не пропадут, пока хранятся на RabbitMQ;
• уведомлениями о сообщениях — RabbitMQ обменивается сигналами с отправителями и получателями.

Элементы, обеспечивающие надежность

Зеркалирование очереди

Очереди могут быть зеркалированы (реплицированы) на многих узлах (серверах). Для каждой очереди предусмотрена ведущая очередь на одном из узлов. Например, есть три узла, 10 очередей и по две реплики на очередь. 10 контрольных очередей и 20 реплик будет распределено по трём узлам. Распределение контрольных очередей по узлам может быть настроено. В случае зависания узла:

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

Надёжные очереди

На RabbitMQ предусмотрено два типа очередей: надёжные и ненадёжные. Надёжные очереди записываются на диск и сохраняются в случае перезагрузки узла. При запуске узла они переопределяются.

Устойчивые сообщения

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

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

Уведомления о получении сообщений

Передача сообщений

Сообщения могут быть утеряны или дублированы при передаче. Это зависит от поведения отправителя.

“Выстрелил и забыл”

Источник может решить не запрашивать от получателя подтверждения (уведомления о получении сообщения для отправителя) и просто отправить сообщение в автоматическом режиме. Сообщения не будут дублироваться, но могут потеряться (что удовлетворяет стратегии “как максимум однократная доставка”).

Подтверждения отправителю

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

• basic.ack. Положительное подтверждение. Сообщение получено, ответственность за него теперь лежит на RabbitMQ;
• basic.nack. Негативное подтверждение. Что-то случилось, и сообщение не было обработано. Ответственность за него остаётся на источнике. При желании, он может отправить сообщение вторично.

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

Теперь, когда имеется множество сообщений, находящихся в пути от отправителя к RabbitMQ, для повышения производительности группируются подтверждения, используя флаг multiple. Всем сообщениям, отправляемым по каналу, присваивается монотонно возрастающее целое значение, “порядковый номер” (Sequence Number). Уведомление о поступлении сообщения включает порядковый номер соответствующего сообщения. И если при этом значение multiple=true, отправитель должен отслеживать порядковые номера своих сообщений, чтобы знать, какие сообщения были успешно доставлены, а какие нет. Я написал подробную статью на эту тему.

Благодаря подтверждениям мы избегаем потерь сообщений следующими способами:

• переотправка сообщений в случае поступления негативного уведомления;
• продолжение хранения сообщений где-нибудь в случае получения негативного уведомления или basic.return.

Транзакции редко используются в RabbitMQ по следующим причинам:

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

Ошибки средств коммуникации/каналов

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

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

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

Отправителю невозможно это определить, поэтому он должен выбрать один из следующих вариантов:

• не переотправлять сообщение, создавая риск его утери;
• переотправлять сообщение и создать риск его дублирования.

Получатели

Получателям доступны две опции, регулирующие уведомления о получении:

• режим отсутствия уведомлений;
• ручной режим уведомлений.

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

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

Ручной режим уведомлений

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

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

Уведомления могут быть следующие:

• basic.ack. После него RabbitMQ удаляет сообщение из очереди. Здесь может быть применён флаг multiple.
• basic.nack. Получатель обязан установить флаг, чтобы сообщить RabbitMQ, ставить ли сообщение заново в очередь. При повторной постановке сообщение попадает в начало очереди. Оттуда оно отправляется получателю опять (даже тому же получателю). Уведомление basic.nack поддерживает флаг multiple.
• basic.reject. То же, что и basic.nack, только не поддерживает флаг multiple.

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

Ошибка соединения/брокера сообщений

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

Чем дольше у получателя долгое время имеются сообщения, получение которых он не подтвердил, тем выше риск переотправки. Когда сообщение отправляется повторно, RabbitMQ для флага переотправки устанавливает значение “true”. Благодаря этому получатель по крайней мере имеет индикацию того, что сообщение, возможно, уже было обработано.

Идемпотентность

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

Заключение

RabbitMQ предоставляет надёжные, долговременные гарантии обмена сообщениями, но есть много ситуаций, когда они не помогут.

Вот список моментов, которые следует запомнить:

• Следует применять зеркалирование очередей, надёжные очереди, устойчивые сообщения, подтверждения для отправителя, флаг подтверждения и принудительное уведомление от получателя, если требуются надёжные гарантии в стратегии “как минимум однократная доставка”.
• Если отправка производится в рамках стратегии “как минимум однократная доставка”, может потребоваться добавить механизм дедубликации или идемпотентности при дублировании отправляемых данных.
• Если вопрос потери сообщений не так важен, как вопрос скорости доставки и высокой масштабируемости, то подумайте о системах без резервирования, без устойчивых сообщений и без подтверждений на стороне источника. Я всё же предпочел бы оставить принудительные уведомления от получателя, чтобы контролировать поток принимаемых сообщений путем изменения ограничений предвыборки. При этом вам потребуется отправлять уведомления пакетами и использовать флаг “multiple”.

Гарантии доставки обеспечиваются:

• долговечностью сообщений — сообщения, сохранённые в сегменте, не теряются;
• Уведомлениями о сообщениях — обмен сигналами между Kafka (и, возможно, хранилищем Apache Zookeeper) с одной стороны и источником/получателем — с другой.

Одно из отличий RabbitMQ от Kafka заключается в использовании пакетов при обмене сообщениями.

RabbitMQ обеспечивает что-то похожее на пакетирование благодаря:

• Приостановке отправки каждые Х сообщений до тех пор, пока не будут получены все уведомления. RabbitMQ обычно группирует уведомления, используя флаг «multiple».
• Установке получателями параметра «prefetch» и группировкой уведомлений с помощью «multiple».

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

Kafka более эффективно работает с пакетами со стороны получателя, потому что работа распределяется по разделам, а не по конкурирующим получателям. Каждый раздел закреплён за одним получателем, поэтому даже применение больших пакетов не влияет на распределение работы. Но если вместе с RabbitMQ используется устаревший API для считывания больших пакетов, это может привести к крайне неравномерной нагрузке между конфликтующими между собой получателями и значительным задержкам в обработке данных. RabbitMQ по своему устройству не подходит для пакетной обработки сообщений.

Элементы, обеспечивающие устойчивость

Репликация журнала

Для защиты от сбоев у Kafka предусмотрена архитектура ведущий-ведомый на уровне раздела журнала, и в этой архитектуре ведущие называются лидерами, а ведомые еще могут называться репликами. Лидер каждого сегмента может иметь несколько ведомых. Если на сервере, где находится лидер, происходит сбой, предполагается, что реплика становится лидером и все сообщения сохраняются, только обслуживание на короткое время прерывается.

Kafka придерживается концепции синхронизации реплик (In Sync Replicas, ISR). Каждая реплика может быть или не быть в синхронизированном состоянии. В первом случае она получает те же сообщения, что и лидер, за короткий отрезок времени (обычно за последние 10 секунд). Она выпадает из синхронизации, если не успевает эти сообщения принять. Такое может произойти из-за сетевой задержки, проблем с виртуальной машиной узла и т.д. Потеря сообщений может произойти только в случае сбоя лидера и отсутствия участвующих в синхронизации реплик. Я расскажу об этом подробнее в следующей части.

Уведомления о получении сообщений и отслеживание смещения

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

Уведомление о получении сообщения для источника

Когда источник посылает сообщение, он даёт знать брокеру Kafka, какого рода уведомление он хочет получить, задав одну из настроек:

• Без уведомлений, автоматический режим. Acks=0.
• Уведомление о получении сообщения лидером. Acks=1
• Уведомление о получении сообщения лидером и всеми участвующими в синхронизации репликами. Acks=All

Однако у Kafka предусмотрена хорошая опция против проблем с дублированием. Для её работы должны быть соблюдены следующие условия:

• для enable.idempotence установлено значение “true”,
• для max.in.flight.requests.per.connection установлено значение 5 или менее,
• для retries установлено значение 1 или выше,
• для acks установлено значение “all”.

Отслеживание смещения получателем

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

Когда получатель считывает пакеты сообщений из раздела (топика), у него есть несколько вариантов относительно того, когда сохранять смещение своего последнего полученного сообщения:

• Периодически. По мере обработки сообщений клиентская библиотека контролирует периодические фиксации смещения. Это делает работу со смещениями очень простой с точки зрения программиста и также положительно влияет на производительность. Но такой подход повышает риск повторной доставки при сбое получателя. Получатель может успеть обработать пакет сообщений и упасть прежде, чем он успеет зафиксировать соответствующее смещение.
• Немедленно, перед началом обработки сообщений. Это соответствует стратегии отправки сообщений “как максимум однократная доставка”. При этом не важно, когда могли быть сбои у получателя; сообщение не будет обработано дважды, но может остаться необработанным. Например, если 10 сообщений обрабатывались и на пятом у получателя произошёл сбой, обработанными окажутся только 4 сообщения, остальные будут сброшены, и следующий получатель начнёт с сообщений, которые поступят после этого пакета;
• В конце, когда все сообщения обработаны. Это соответствует стратегии отправки сообщений “как минимум однократная доставка”. Не важно, когда могли быть сбои у получателя, ни одно сообщение не останется необработанным, но одно и то же сообщение может быть обработано несколько раз. Например, если 10 сообщений обрабатывались и на пятом у получателя произошёл сбой, все десять сообщений будут считаны следующим получателем, и 4 сообщения окажутся обработаны дважды;
• Поочередно. Это сократит возможность дублирования, но сильно снизит производительность работы.

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

О транзакциях и уровнях изоляции

Главным сценарием применения транзакций в Kafka является упомянутый выше сценарий “чтение-обработка-написание”. В транзакции могут участвовать сразу несколько топиков и разделов. Отправитель начинает транзакцию, создаёт пакет сообщений, завершает транзакцию.

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

Может возникнуть вопрос: как изоляционный уровень “чтение завершенных транзакций” влияет на гарантии порядка отправки сообщений? Он не влияет никак. Получатели будут считывать все сообщения в нужном порядке, это прекратится на первом сообщении, транзакция которого не завершена. Незавершенные транзакции будут блокировать чтение. Смещение последней завершенной транзакции (Last Stable Offset, LSO) — это смещение до первой незавершенной транзакции; получатели с уровнем изоляции “чтение завершенных транзакций” могут читать только до данного смещения.

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

Подведём итоги

• Обе платформы способны реализовать стратегии “как максимум однократная доставка” и “как минимум однократная доставка”.
• Обе платформы обеспечивают репликацию сообщений.
• На обеих платформах действуют одинаковые факторы, в силу которых следует искать компромисс между пропускной способностью системы и риском дублирования сообщений. Kafka обеспечивает идемпотентную отправку сообщений, но только для ограниченного объёма трафика.
• Обе платформы задают ограничения количества передаваемых сообщений, находящихся в пути, подтверждение о получении которых ещё не получено отправителем.
• Обе платформы предоставляют гарантии относительно порядка отправки сообщений.
• Kafka обеспечивает поддержку транзакций, в первую очередь в сценарии “чтение-обработка-написание”. При этом нужно принять меры против снижения пропускной способности системы.
• В Kafka, если получатель не обрабатывает часть сообщений из-за сбоев техники и некорректного отслеживания смещения последнего полученного сообщения, все равно можно восстановить смещение этого сообщения (если такой случай обнаружен). В RabbitMQ соответствующие сообщения будут утеряны.
• Kafka может повысить пользу от пакетирования благодаря своим возможностям по распределению пакетов, а в RabbitMQ пакетирование отсутствует в силу пассивной модели приёма, не препятствующей конфликтам получателей.

• Блог компании ITSumma
• Высокая производительность
• Мессенджеры
• Apache
• Big Data

Параметры асинхронного обмена сообщениями

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

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

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

Команды

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

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

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

События

Событие — это тип сообщения, которое производитель поднимает для объявления фактов.

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

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

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

Существует две категории событий:

• Продюсер поднимает события, чтобы объявить дискретные факты. Распространенным вариантом использования является уведомление о событии. Например, Azure Resource Manager вызывает события при создании, изменении или удалении ресурсов. Подписчиком этих событий может быть приложение логики, которое отправляет оповещения по электронной почте.
• Производитель вызывает связанные события в последовательности или поток событий в течение определенного периода времени. Как правило, поток используется для статистической оценки. Оценка может происходить в временном окне или по мере поступления событий. Телеметрия — это распространенный вариант использования (например, мониторинг работоспособности и нагрузки системы). Другим случаем является потоковая передача событий с устройств Интернета вещей.

Распространенный шаблон реализации обмена сообщениями о событиях — шаблон издателя-подписчика .

Роль и преимущества брокера сообщений

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

Разъединение

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

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

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

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

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

Балансировка нагрузки

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

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

Выравнивание нагрузки

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

Шаблон выравнивания нагрузки на основе очередей предоставляет дополнительные сведения.

Надежный обмен сообщениями

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

Устойчивое обмен сообщениями

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

Выбор технологии для брокера сообщений

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

Службы сообщений Служебной шины Azure

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

Модель извлечения

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

Гарантированная доставка

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

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

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

Порядок сообщений

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

Дополнительные сведения см. в статье Сеансы обмена сообщениями.

Сохраняемость сообщений

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

Длительные транзакции контрольной точки

Бизнес-транзакции могут выполняться в течение длительного времени. Каждая операция в транзакции может содержать несколько сообщений. Используйте проверка указание для координации рабочего процесса и обеспечения устойчивости в случае сбоя транзакции.

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

Очередь недоставленных писем (DLQ)

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

Ниже приведены примеры того, когда сообщение может оказаться в DLQ:

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

Проверьте сообщения в DLQ, чтобы определить причину сбоя.

Гибридное решение

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

Шаблон моста обмена сообщениями — это другой способ обработки этих сценариев.

Разделы и подписки

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

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

Дополнительные сведения см. в Служебная шина Azure разделах.

Сетка событий Azure

Мы рекомендуем Сетка событий Azure для дискретных событий. Сетка событий следует шаблону publisher-подписчика. Когда источники событий активируют события, они публикуются в разделах Сетки событий. Потребители этих событий создают подписки сетки событий, указывая типы событий и обработчик событий, которые будут обрабатывать события. Если нет подписчиков, события не карта. Каждое событие может иметь несколько подписок.

Модель принудительной отправки

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

Интеграция с Azure

Выберите сетку событий, если вы хотите получать уведомления о ресурсах Azure. Многие службы Azure служат источниками событий, которые имеют встроенные разделы сетки событий. Сетка событий также поддерживает различные службы Azure, которые можно настроить в качестве обработчиков событий. Легко подписаться на эти разделы, чтобы перенаправить события в обработчики событий вашего выбора. Например, можно использовать сетку событий для вызова функции Azure при создании или удалении хранилища BLOB-объектов.

Пользовательские темы

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

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

Отфильтрованные события

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

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

Дополнительные сведения о фильтрации см. в разделе «Фильтрация событий» для сетки событий.

Высокая пропускная способность

Сетка событий может направлять 10 000 000 событий в секунду в каждом регионе. Первые 100 000 операций в месяц не оплачиваются. Рекомендации по затратам см. в статье о стоимости сетки событий?

Устойчивость доставки

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

Процесс повторных попыток сетки событий может помочь в устойчивости, но он не является отказоустойчивой. В процессе повторных попыток сетка событий может доставлять сообщение несколько раз, пропускать или задерживать некоторые повторные попытки, если конечная точка не отвечает в течение длительного времени. Дополнительные сведения см. в разделе «Расписание повторных попыток».

Вы можете сохранить незавершенные события в учетной записи хранения BLOB-объектов, включив недоставленную букву. Существует задержка при доставке сообщения в конечную точку хранилища BLOB-объектов, а если эта конечная точка не отвечает, то сетка событий не отвечает карта событие. Дополнительные сведения см. в разделе «Настройка расположения недоставленных букв» и политики повторных попыток.

Центры событий Azure

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

Быстрое прием

Центры событий могут обрабатывать миллионы событий в секунду. События добавляются только к потоку и упорядочиются по времени.

Модель извлечения

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

Обработчики потоков — это подписчики, которые извлекают данные из Центров событий в целях преобразования и статистического анализа. Используйте Azure Stream Analytics и Apache Spark для сложной обработки, например агрегирования с течением времени или обнаружения аномалий.

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

Секционирование

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

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

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

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

Дополнительные сведения о секционирования Центров событий см. в разделах Секционирования.

Функция «Сбор» в Центрах событий

Функция отслеживания позволяет хранить поток событий в хранилище BLOB-объектов Azure или Data Lake служба хранилища. Этот способ хранения событий является надежным, так как даже если учетная запись хранения недоступна, запись сохраняет данные в течение определенного периода, а затем записывает данные в хранилище после его доступности.

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

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

Поддержка клиентов Apache Kafka

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

Дополнительные сведения см. в разделе Центры событий для Apache Kafka.

Сценарии кроссоверного перехода

В некоторых случаях выгодно объединить две службы обмена сообщениями.

Объединение служб может повысить эффективность системы обмена сообщениями. Например, в бизнес-транзакции для обработки сообщений используются очереди Служебная шина Azure. Очереди, в основном неактивные и получающие сообщения, иногда неэффективны, потому что потребитель постоянно опрашивает очередь для новых сообщений. Подписку сетки событий можно настроить с помощью функции Azure в качестве обработчика событий. Каждый раз, когда очередь получает сообщение, и потребители не прослушивают, служба «Сетка событий» отправляет уведомление, которое вызывает функцию Azure, которая очищает очередь.

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

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

Ниже приведен еще один пример: Сетка событий получает набор событий, в которых некоторые события требуют рабочего процесса, а другие — для уведомления. Метаданные сообщения указывают тип события. Одним из способов отличия является проверка метаданных с помощью функции фильтрации в подписке на события. Если для него требуется рабочий процесс, сетка событий отправляет ее в очередь Служебная шина Azure. Получатели этой очереди могут выполнять необходимые действия. События уведомлений отправляются в Logic Apps для отправки оповещений.

Связанные шаблоны

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

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