Anton Sidorov homepage

Bookmark this to keep an eye on my project updates!

Follow me on GitHub

RabbitMQ

Зачем

Реализация паттерна интеграции Message Broker.

Критерии выбора.

Плюсы и минусы

Плюсы:

  • «Продажа» Производительность
  • RabbitMQ дает гарантии одноразовой доставки и хотя бы одной доставки, но не ровно одной доставки
  • Message timing control (controlling either message expiry or message delay)
  • Advanced fault handling capabilities, in cases when consumers are more likely to fail to process messages (either temporarily or permanently).
  • Advanced and flexible routing rules
  • Simpler consumer implementations
  • перешли на постоянные (persistent) очереди, которые не удаляются в момент разрыва подключения, но повесили на них политику «протухания» (expire), если пользователя нет более 5 минут
  • Приоритет сообщений

Минусы:

  • Агрегация в пачки нет в RabbitMQ (Kafka Есть)
  • vs Kafka
  • нет параметра Expire для обменников (только для очередей)
  • Нет шардирования, в kafka есть topic-несколько partition, есть несколько инстансов где очереди размещены
  • Производительность ниже Kafka

Функции

Exchange Обменник

  • Типы
    • headers
      • Message is sent to the queues which match the headers.
      • Routing key should not be set. Но если установлены, то можно биндить очередь и по RK.
      • Match type should indicate if ALL (логичекое И) or ANY (логичекое ИЛИ) header must match
    • direct - message is sent to a named exchange, routing key is specified so information only reaches the queues matching the pattern
    • topic - Routing key is a string separated by dots and wildcards. E.g.: “ro.alexandrugris.*”
    • fanout
  • Exchange-to-Exchange (E2E)

Режимы доставки сообщений

  • Basic.get (Pull) - Доставка единичного сообщения по запросу
  • Basic.Consume (Push) - Подписка на очередь (постоянный мониторинг очереди с доставкой всех сообщений)
  • QoS(prefetchCount) Get vs consume
  • http://onreader.mdl.ru/RabbitMQInDepth/content/Ch05.html

Паттерны

Queue

connection

  • 1 Соединение connection на процесс-поток
  • Х каналов channel на каждый поток (не шарить каналы между потоками)
  • На 1 канале channel может быть несколько получателей Consumer из очередей
  • Отдельные соединения для publisher\consumer

Persistence

  • По умолчанию при остановке или падении сервера RabbitMQ все очереди и сообщения теряются, но это поведение можно изменить. Для того чтобы сообщения оставались в очереди после перезапуска сервера, необходимо:
    • сделать как очереди durable
    • так и сообщенния устойчивыми delivery_mode=2
  • TTL Очереди

Интеграции

Task (Worker) Queue

  • Round-robin dispatching (циклическое распределение задач по консьюмерам)
    • сервисы между собой делят Очередь задач
    • паттерн EIP Competing Consumers
    • Exchange type: direct, several consumer listening to the same queue, reading the messages in a round-robin fashion if all are waiting
  • Task Queue (распределение задач по загрузке) Fair dispatching
    • QoS = 1, ack=1, autoack=0 если не подтверждено 1-е сообщение, 2-е пойдёт другому подписчику

Simple one-way messaging

  • Exchange type: direct
  • message sent to unnamed (default queue)

Publish-subscribe Издатель-Подписчик

  • fanout - без фильтрации - события
    • Очередь ответов - даёт широковешательную рассылку ответов по всем ИС потребителям
  • headers - с фильтрацией - события
    • даёт возможность делать фильтрацию трафика на уровне RMQ.
    • подписчик создаёт и связывает очередь к обменнику, указывает фильтрация на основе заголовков - это решает задачу фильтрации лишнего трафика, но не решает задачу изоляции. Подписчик может не указать фильтры и получит весь трафик: и свой и чужой.
  • минусы
    • единый контракт для подписчиков
    • Не безопасно, кто угодно подписывается
    • с ростом числа подписчиков, Брокер масштабировать необходимо
headers vs topic для событий
  • более гибко т.к. key-value инвариантов может быть больше?
    • топик - фильтрация на основе строковой маски - поиска подстроки
    • headers - на основе полного равенства значения ключа (логическое И) или один из ключей (логическое ИЛИ) -минусы
  • функционально разницы нет, по производительности topic в 3 раза медленнее headers

RPC (команды)

Direct Reply-TO

  • мы подписываемся на специальную псевдоочередь amqp.rabbitmq.reply-to
  • отправляем сообщение с указанием этой очереди в качестве reply-to заголовка
  • RMQ генерирует для нас уникальный routing_key, по которому будет должно быть опубликовано ответное сообщение в default exchange
  • сервер получает наше сообщение и отправляет ответ по этому routing_key

MTA

Версионирование типов сообщений

Security

Security mechanism in RabbitMQ:

  • Access control
    • Vhosts
    • each user should be permissioned to only read and write to their own queue based on the queue’s unique name.
  • SASL authentication
    • supports multiple SASL authentication mechanisms. There are three such mechanisms built into the server: PLAIN, AMQPLAIN, and RABBIT-CR-DEMO, and one — EXTERNAL — available as a plugin.
  • SSL support

Observability

Performance

Технологии