Привет!

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

Вообще, если говорить про очереди сообщений, то по факту есть всего 2 модели по которым они работают:

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

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

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

Теперь немного поговорим про остальные отличия RabbitMQ от Kafka:

1️⃣ Производительность:
- RabbitMQ: От 4000 до 10 000 сообщений в секунду
- Kafka: 1 миллион сообщений в секунду

2️⃣Хранение сообщений:
- RabbitMQ: На основе подтверждения
- Kafka: На основе политик (например, 30 дней)

3️⃣Режим работы консьюмера:
- RabbitMQ: Умный брокер/тупой консьюмер
- Kafka: Тупой брокер/умный консьюмер

4️⃣Размер полезных данных:
- RabbitMQ: Без ограничений
- Kafka: По умолчанию – ограничение в 1 МБ

5️⃣Примеры применения:
- RabbitMQ: "Простые" случаи
- Kafka: Массовая обработка данных/высокопроизводительная передача данных

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

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