Что такое RabbitMQ?

Э, слушай, давай разжую про этого кролика, а то смотрю, у некоторых глаза стекленеют от этих терминов. RabbitMQ — это, по сути, такой почтальон Печкин на стероидах для твоих программ. Открытый исходник, протокол AMQP, вся хуйня. Представь: у тебя есть одно приложение, которое орет «ДАННЫЕ!», а другое в это время спит или тупит. Так вот, этот брокер — тот самый буфер, который кричит «Заткнись!» первому и «Проснись, мудак!» второму, чтобы они не наступали друг другу на мозги. Общаются асинхронно, то есть когда хотят, и надёжно, то есть сообщение не потеряется, если всё не накроется медным тазом.

Ключевые роли в этом ёперном театре:

• Producer (Отправитель): Прога, которая палит сообщениями. Как тот чувак на кухне, который кричит «Кушать подано!».
• Exchange (Обменник): Самый главный по распределению, этакий хитрый жопа. Получает крик от отправителя и решает, в какую именно комнату-очередь это послание засунуть. Руководствуется типом себя любимого и ключом маршрутизации.
• Queue (Очередь): Ну это и есть та самая комната, коридор, где сообщения тупо стоят и ждут, пока их не заберут. Буфер, короче.
• Consumer (Получатель): Прога, которая приходит в эту комнату, забирает сообщение и делает с ним что надо. Типа официанта, который разносит еду.

А теперь, блядь, типы этих самых обменников (Exchange). Их три основных, как три кита:

1. Direct (Прямой): Тупой как пробка. Сообщение летит ТОЛЬКО в ту очередь, чье имя (binding key) точно совпадает с тем, что крикнул отправитель (routing key). Никаких фокусов. «Вася» — только «Васе».
2. Fanout (Веерный): Абсолютный распиздяй. Получил сообщение — и разослал его ВО ВСЕ привязанные к нему очереди без разбора. Похуй на ключи. Просто широковещание, как в чате «@all».
3. Topic (Топик): Уже хитрая жопа. Тут есть шаблоны. Можно сказать: «Отправь всё про логи (logs.) и ошибки (.error) в очередь X». Сообщение с ключом logs.app.error — попадёт. А logs.app.info — уже нет. Гибко, мощно.

Смотри, как это выглядит в коде на C++ (библиотека AMQP-CPP). Не пугайся, я комментарии оставил:

#include <amqpcpp.h>
#include <amqpcpp/libev.h>
#include <ev.h>

int main() {
    // Заводим движок для событий (libev) — это как завести машину
    auto *loop = EV_DEFAULT;
    AMQP::LibEvHandler handler(loop);

    // Подключаемся к самому брокеру-кролику (гость/гость на локалхосте)
    AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://guest:guest@localhost/"));
    AMQP::TcpChannel channel(&connection); // Открываем канал для общения

    // Объявляем очередь. Назовём её "task_queue". Флаг AMQP::durable — это чтобы очередь пережила перезагрузку RabbitMQ.
    channel.declareQueue("task_queue", AMQP::durable);

    // Публикуем сообщение. Первый аргумент — пустая строка (используем дефолтный обменник, он типа Direct).
    // Второй — имя очереди ("task_queue"). Третий — само сообщение.
    channel.publish("", "task_queue", "Hello, RabbitMQ from C++!");
    std::cout << " [x] Sent 'Hello, RabbitMQ from C++!'" << std::endl;

    // Запускаем цикл обработки событий. Прога будет ждать, пока всё отправится.
    ev_run(loop, 0);

    return 0;
}

И нахуй это всё, спросишь? А вот нахуй:

• Развязать сервисы: Отправителю абсолютно похуй, жив получатель или нет. Он кинул сообщение в обменник и пошёл дальше пить кофе. Доверия ебать ноль между ними, и это хорошо.
• Гарантировать доставку: Сообщение можно пометить как стойкое (persistent), и даже если кролик упадёт, он его с диска потом дочитает. Не как в UDP — отправил и молюсь.
• Балансировать нагрузку: Можно на одну очередь навесить овердохуища получателей. RabbitMQ будет умно раздавать сообщения между ними по кругу, чтобы никто не простаивал и не перегревался.
• Буферизовать запросы: Получатель лег спать? Поломался? Да похуй. Сообщения будут терпеливо ждать его в очереди, а не сгорать таймаутом. Как почтовый ящик, блядь.

Вот и вся магия. Не так страшен кролик, как его малюют. Главное — понять, кто в твоей архитектуре кричит, кто слушает, и какого хуя они друг другу мешают.