Loading...

📬

Очередь сообщений(MQ)

Асинхронная система передачи сообщений, обеспечивающая слабосвязанную коммуникацию между ИИ-агентами и сервисами в распределённых агентных системах

Сложность: highМультиагентные системы

In 30 seconds

What: Агенты отправляют сообщения в очереди вместо прямых вызовов друг друга, что обеспечивает асинхронную работу и развязывает зависимости между сервисами.
When to use: Нескольким агентам нужно координировать работу без взаимных блокировок, справляться с переменной нагрузкой или восстанавливаться после сбоев, не теряя задач.
Watch out: Порядок сообщений и обработка дубликатов усложняются; отлаживать распределённые сбои сразу в очереди, у производителя и у потребителя значительно труднее.

Loading technique guide…

Patterns

Loading...

Паттерны и методы проектирования

Loading...

📬

Очередь сообщений(MQ)

Сложность: highМультиагентные системы

In 30 seconds

What: Агенты отправляют сообщения в очереди вместо прямых вызовов друг друга, что обеспечивает асинхронную работу и развязывает зависимости между сервисами.
When to use: Нескольким агентам нужно координировать работу без взаимных блокировок, справляться с переменной нагрузкой или восстанавливаться после сбоев, не теряя задач.
Watch out: Порядок сообщений и обработка дубликатов усложняются; отлаживать распределённые сбои сразу в очереди, у производителя и у потребителя значительно труднее.

Основной механизм

Очереди сообщений обеспечивают асинхронное, слабосвязанное взаимодействие между производителями и потребителями через долговечные очереди. Брокеры дают гарантии доставки (at-least-once, at-most-once, иногда exactly-once), варианты упорядочивания (по партиции/группе), подтверждения, повторы и обработку недоставленных сообщений. Распространённые реализации: Apache Kafka (партиции на основе лога, группы потребителей), RabbitMQ/AMQP (очереди, обменники, привязки), облачные очереди AWS SQS и Google Pub/Sub, NATS JetStream и Redis Streams.

Процесс / Шаги

Производитель публикует сообщение (при необходимости с ключом для упорядочивания или партиционирования).
Брокер сохраняет/ставит в очередь и реплицирует (согласно настройкам), предоставляя лаг/смещения потребителей или глубину очереди.
Потребитель забирает/получает сообщения с prefetch и управлением потоком; обрабатывает их в рамках таймаута и бюджета.
При успехе подтверждать; при сбое повторять с backoff или направлять в очередь недоставленных сообщений (DLQ).
Операторы отслеживают метрики и настраивают партиции, потребителей и квоты ради пропускной способности и SLO.

Лучшие практики

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

Ограничивать обработку таймаутами; применять экспоненциальный backoff с джиттером; ограничивать повторы и использовать DLQ.

Явно выбирать семантику доставки; документировать гарантии порядка для каждого топика/очереди.

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

Применять обратное давление: настраивать prefetch и управление потоком; при необходимости пакетировать; ограничивать число сообщений в обработке.

Проверять схемы сообщений (например, Avro/Protobuf/JSON Schema); использовать реестр схем и правила совместимости.

Изолировать побочные эффекты; применять шаблон Outbox для атомарности БД→очередь; обеспечивать exactly-once там, где это поддерживается.

Шифровать при передаче и хранении; обеспечивать авторизацию (RBAC, IAM) и квоты по арендаторам.

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

Наблюдать: выдавать лаг, глубину очереди, число повторных отправок, причины сбоев; добавить трассировку по ID сообщений.

Когда НЕ использовать

Синхронные пути запрос/ответ со сверхнизкой задержкой, где накладные расходы очереди ломают SLO → предпочтительнее прямой RPC (gRPC/REST).

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

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

Типичные ошибки

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

Неидемпотентные побочные эффекты при повторах → дубликаты и повреждение данных.

Неограниченный рост очередей и лаг потребителей из-за отсутствия обратного давления или недостаточного масштабирования.

Штормы повторов и эффект «стада»; нет предохранителей и backoff с джиттером.

Крупные payload в брокере; отсутствие стратегии эволюции схем приводит к поломке потребителей.

Ключевые особенности

Семантика доставки: at-least-once / at-most-once / exactly-once (зависит от платформы).

Управление порядком: ключи партиций, FIFO-группы, ключи упорядочивания.

Долговечность и репликация; политики подтверждения и повторной доставки.

DLQ, TTL и отложенная либо запланированная доставка.

Группы потребителей, prefetch/управление потоком и обратное давление.

Реестр схем и режимы совместимости; версионирование сообщений.

KPI / Метрики успеха

Сквозная задержка p50/p95/p99; задержка публикации и потребления.

Пропускная способность (сообщений/с, МБ/с) по топикам/очередям и группам потребителей.

Лаг потребителей и глубина очереди; возраст старейшего сообщения; доля повторных отправок/DLQ.

Доли повторов и дубликатов; доли успешной/неуспешной обработки; MTTR.

Состояние брокера: ISR/репликация, баланс лидеров партиций, использование хранилища.

KPI стоимости: исходящий трафик, хранилище, плата за запросы (для управляемых сервисов).

Использование токенов / ресурсов

Профиль ресурсов: CPU для сериализации/сжатия и координации брокера; память для буферов; дисковый ввод-вывод для долговечных логов; сеть для репликации и клиентского трафика.

Оптимизировать пакетированием и сжатием; правильно подбирать число партиций и параллелизм потребителей; ограничивать размер сообщений (например, SQS 256 КБ, Pub/Sub 10 МБ, Kafka настраивается).

Не встраивать крупные блобы; хранить их снаружи и отправлять ссылки; применять квоты и лимиты запросов по арендаторам.

Лучшие сценарии применения

Развязка микросервисов; асинхронные процессы; обработка фоновых задач.

Событийные архитектуры и веерная обработка; журналы аудита и событий.

Выравнивание нагрузки и сглаживание всплесков; управление обратным давлением у нижестоящих систем.

Буферизация между регионами и устойчивость к прерывистой связи.

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Apache Kafka, RabbitMQ, AWS SQS, Google Pub/Sub, NATS JetStream, Redis Streams
Клиентские SDK: клиенты librdkafka/Confluent, Sarama (Go), Spring Kafka/AMQP, aio-pika, AWS SDK
Очереди заданий: Celery, Sidekiq, Resque, BullMQ, RQ

Loading...

Очередь сообщений(MQ)

In 30 seconds

Patterns

Loading...

Паттерны и методы проектирования

Loading...

Очередь сообщений(MQ)

In 30 seconds

Основной механизм

Процесс / Шаги

Лучшие практики

Когда НЕ использовать

Типичные ошибки

Ключевые особенности

KPI / Метрики успеха

Использование токенов / ресурсов

Лучшие сценарии применения

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Сообщество и обсуждения

Patterns

Паттерны и методы проектирования

Loading...

Паттерны и методы проектирования

Основной механизм

Процесс / Шаги

Лучшие практики

Когда НЕ использовать

Типичные ошибки

Ключевые особенности

KPI / Метрики успеха

Использование токенов / ресурсов

Лучшие сценарии применения

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Сообщество и обсуждения

Паттерны и методы проектирования