Что такое RabbitMQ и его роль в архитектуре?

Давай разжую про этого кролика, чтобы ты понял, насколько эта мартышлюшка хитрая. RabbitMQ — это, по сути, такой почтальон-трудяга, который таскает сообщения туда-сюда между твоими сервисами, чтобы они друг другу в душу не лезли и не орали «какого хуя ты мне не отвечаешь?». Реализует он протокол AMQP, но тебе, честно говоря, да похуй на эту аббревиатуру. Главное — он берёт твоё сообщение, пиздует его в нужную очередь, и оно там сидит, пока какой-нибудь потребитель не приползёт и не обработает. Всё гениально и просто, как хуй с горы.

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

Из чего этот зверинец состоит:

1. Producer (Издатель): Это тот чувак, который кричит «Эй, у меня тут событие!». Например, сервис заказов, который орет, что заказ создан.
2. Exchange (Обменник): Центральный распределительный щит, ёперный театр. Получает сообщение от крикуна и решает, в какую именно очередь его послать. У него есть типы, от которых у новичков удивление пиздец:
   • Direct: Тупое попадание. Сообщение идёт только в ту очередь, чей ключ (routing key) совпал с ключом сообщения. Точно в цель.
   • Fanout: Похуй на ключи. Рассылает сообщение во все дыры, во все привязанные очереди. Как спам в общий чат.
   • Topic: Умная маршрутизация по шаблону. Типа logs.*.error — сюда подойдёт и logs.app.error, и logs.db.error. Гибко, мощно.
   • Headers: Вообще поехавший тип. Маршрутизирует по заголовкам сообщения, а не по ключу. Для особых эстетов.
3. Queue (Очередь): Просто очередь, блядь. Конвейер. Сообщения тут тупо висят и ждут своего часа.
4. Consumer (Потребитель): Тот самый работяга, который выгребает сообщения из очереди и делает полезную работу. Например, шлёт письмо.

Смотри, как это выглядит в коде на PHP (библиотека php-amqplib):

Отправка сообщения (Producer — крикун):

<?php
require_once __DIR__ . '/vendor/autoload.php';
use PhpAmqpLibConnectionAMQPStreamConnection;
use PhpAmqpLibMessageAMQPMessage;

// Подключаемся к кролику
$connection = new AMQPStreamConnection('localhost', 5672, 'guest', 'guest');
$channel = $connection->channel();

// Объявляем обменник. Скажем ему: будь типа 'direct', будь устойчивым (true), не удаляйся сам.
$channel->exchange_declare('order_events', 'direct', false, true, false);
// Объявляем очередь для писем. Пусть тоже будет durable (true), чтобы пережила перезагрузку.
$channel->queue_declare('email_queue', false, true, false, false);
// Привязываем эту очередь к обменнику. Говорим: "Слушай, обменник 'order_events', если придёт сообщение с ключом 'order.created' — шли его в 'email_queue'".
$channel->queue_bind('email_queue', 'order_events', 'order.created');

// Само сообщение. JSON, как же без него.
$messageBody = json_encode(['order_id' => 789, 'user_email' => 'user@example.com']);
// Упаковываем. DELIVERY_MODE_PERSISTENT — это чтобы кролик сохранил его на диск, а не в оперативку.
$msg = new AMQPMessage($messageBody, ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]);

// Публикуем нахуй! В обменник 'order_events' с ключом 'order.created'.
$channel->basic_publish($msg, 'order_events', 'order.created');

// Закрываем лавочку.
$channel->close();
$connection->close();

Получение сообщения (Consumer — работяга):

<?php
require_once __DIR__ . '/vendor/autoload.php';
use PhpAmqpLibConnectionAMQPStreamConnection;

// Подключаемся так же
$connection = new AMQPStreamConnection('localhost', 5672, 'guest', 'guest');
$channel = $connection->channel();

// Это колбэк — что делать, когда сообщение припёрлось.
$callback = function (AMQPMessage $msg) {
    $data = json_decode($msg->body, true);
    echo " [x] Получил заказ #" . $data['order_id'] . " для мыла " . $data['user_email'] . "n";
    // Тут твоя логика: отправить письмо, сходить в базу, etc.
    // ...
    $msg->ack(); // Кричим кролику: «Всё, чувак, я обработал, можешь удалять сообщение из очереди!». Это важно, иначе он подумает, что ты сдох, и отдаст его другому.
};

// Настраиваем качество обслуживания: не грузи работягу, пусть берёт по одному сообщению.
$channel->basic_qos(null, 1, null);
// Подписываемся на очередь. false, false, false — это про auto_ack и exclusive. Нам ручное подтверждение (ack).
$channel->basic_consume('email_queue', '', false, false, false, false, $callback);

// Вечный цикл, слушаем очередь.
while ($channel->is_consuming()) {
    $channel->wait();
}

И зачем этот цирк, спросишь? Преимущества — ебушки-воробушки:

• Развязка сервисов: Сервис заказов нихуя не знает про сервис отправки писем. Он просто крикнул в обменник и пошёл дальше. Если сервис писем накрылся медным тазом, заказы от этого не встанут — сообщения будут ждать в очереди.
• Гарантированная доставка: Сообщения можно сохранять на диск. Перезагрузил кролика — а они всё там, живы-здоровы.
• Гибкая маршрутизация: Тот самый хитрая жопа с обменниками. Хочешь разослать событие десяти сервисам? Fanout — и нет проблем. Нужна сложная фильтрация? Topic тебе в помощь.
• Балансировка нагрузки: Можно запустить овердохуища экземпляров потребителей на одной очереди. Кролик будет сам раскидывать им сообщения по кругу. Автоматическая балансировка, красота.
• Отказоустойчивость: Кролика можно поставить кластером, очереди зазеркалить. Если одна нода пизда рулю, другая подхватит.

Где это впаривают? Везде: фоновая отправка мыл и смс, обработка тяжелых отчетов (чтобы пользователь не пялился в экран), интеграция старых и новых систем, буферизация запросов, когда от клиентов летит манда с ушами, а обрабатывать всё сразу нельзя. В общем, вещь.