RabbitMQ.

RabbitMQ отличие от Kafka.

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

Что такое синхронные и асинхронные взаимодействия?

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

Основными моделями взаимодействия являются синхронные и асинхронные подходы.

Синхронные взаимодействия.

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

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

Ключевые характеристики синхронного взаимодействия:

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

Асинхронные взаимодействия.

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

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

Ключевые характеристики асинхронного взаимодействия:

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

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

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

Типы обменников RabbitMQ.

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

Первый тип обменника — это Direct Exchange или Прямой обменник. Он направляет сообщения в очереди на основе точного совпадения ключа маршрутизации (routing key). Это удобно, когда нужно направлять сообщения в конкретные очереди, например, по идентификатору события или типу задачи. Как вариант, нужно отправить заказ на оплату в систему, и ключ маршрутизации «order.payment» направляет это сообщение в очередь, отвечающую за обработку платежей.
Второй тип — это Fanout Exchange. Этот тип обменника игнорирует ключ маршрутизации и направляет сообщения во все привязанные к нему очереди. Он полезен для широковещательной передачи сообщений. Например, событие создания нового заказа может быть отправлено сразу во все очереди, чтобы уведомить разные системы — склад, бухгалтерию, отдел доставки и т.д. о новом заказе.
Третий вариант — это Topic Exchange или Топиковый обменник. Он использует шаблоны маршрутизации для направления сообщений в очереди. Шаблоны позволяют гибко маршрутизировать сообщения, например, «order.*» может направлять все сообщения, связанные с заказами. Сообщения с ключами «order.created», «order.cancelled» и «order.paid» могут быть направлены в разные очереди, в зависимости от типа события.
Четвертый вариант — это Headers Exchange. Этот тип обменника использует заголовки сообщений для маршрутизации, что позволяет выполнять маршрутизацию на основе произвольных метаданных. Сообщения могут быть направлены в разные очереди в зависимости от их заголовков, например, важности сообщения или типа клиента.

Тестирование асинхронных взаимодействий с RabbitMQ.

Проверка маршрутизации сообщений.

Тестировщик может проверять правильность маршрутизации сообщений, отправляя их в разные обменники и наблюдая за тем, в какие очереди они попадают. Для этого можно использовать инструменты мониторинга, встроенные в RabbitMQ, такие как RabbitMQ Management Plugin. Тестировщик отправляет сообщение с определенным ключом маршрутизации (например, «order.payment») и проверяет, что сообщение действительно попало в нужную очередь, например, очередь для обработки платежей.

Для этого могут быть выполнены следующие шаги:

Открыть RabbitMQ Management Plugin и перейти в раздел Exchanges.
Отправить сообщение через UI или с помощью специального инструмента (например, Postman, используя HTTP API RabbitMQ).
Проверить, что сообщение появилось в правильной очереди в разделе Queues и соответствует ключу маршрутизации.

Проверка обработки сообщений потребителями.

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

Тестировщик может:

Отправить тестовое сообщение в очередь.
Перейти в RabbitMQ Management Plugin и выбрать нужную очередь в разделе Queues. Должно быть видно, что сообщение появилось в очереди.
Понаблюдать за потребителем. Потребитель должен забрать сообщение из очереди, после чего количество сообщений в очереди должно уменьшиться до 0. В интерфейсе RabbitMQ в разделе Consumers можно увидеть активных потребителей, которые подключены к очередям и обрабатывают сообщения.
Если система настроена на подтверждение сообщений (ACK), убедиться, что после получения сообщения оно удаляется из очереди.

Тестирование подтверждений (ACK).

RabbitMQ поддерживает механизм подтверждений (ACK) — это значит, что после обработки сообщения потребитель отправляет RabbitMQ подтверждение, что сообщение успешно обработано. Если потребитель не отправит ACK, сообщение останется в очереди или будет повторно доставлено.

Для тестирования этого процесса тестировщик должен:

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

Тестирование отказоустойчивости.

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

Основные сценарии для проверки:

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

Примерный сценарий такого тестирования может выглядеть так:

Отправить сообщение в очередь.
Остановить потребителя или отключить его от сети.
Убедиться, что сообщение осталось в очереди.
Перезапустить потребителя и убедиться, что сообщение забирается и обрабатывается после восстановления подключения.

Нагрузочное тестирование RabbitMQ.

Для ручного тестировщика нагрузочные тесты можно проводить с помощью инструментов, таких как Apache JMeter, который поддерживает работу с RabbitMQ через AMQP-протокол. Этот инструмент позволяет имитировать высокую нагрузку на систему и отслеживать, как RabbitMQ справляется с большим количеством сообщений и потребителей.

Тестировщик может настроить сценарий, в котором сотни или тысячи сообщений отправляются в RabbitMQ, и проверить:

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