Ответ
Fanout ("веерная рассылка") — это архитектурный паттерн в системах обмена сообщениями, при котором одно входящее сообщение или событие доставляется множеству получателей (потребителей) одновременно. Это основа модели Publish/Subscribe (Pub/Sub).
Как это работает:
- Издатель (Publisher) отправляет сообщение не напрямую в очередь, а в exchange (топик).
- Exchange типа fanout игнорирует ключи маршрутизации и просто копирует сообщение во все очереди, которые с ним связаны.
- Каждый Подписчик (Subscriber/Consumer), слушающий свою очередь, получает копию этого сообщения.
Типичный Use Case в PHP-приложениях: Рассылка уведомлений о системном событии (например, UserRegistered) разным независимым сервисам.
// Publisher (используя библиотеку php-amqplib)
$connection = new AMQPStreamConnection('rabbitmq', 5672, 'guest', 'guest');
$channel = $connection->channel();
// Объявляем exchange типа 'fanout' с именем 'user_events'
$channel->exchange_declare('user_events', 'fanout', false, false, false);
$eventData = json_encode(['user_id' => 123, 'email' => 'user@example.com']);
$msg = new AMQPMessage($eventData);
// Публикуем сообщение в exchange. Ключ маршрутизации (routing_key) не важен для fanout.
$channel->basic_publish($msg, 'user_events');
// Subscriber 1 (Сервис отправки email)
$channel->queue_declare('email_service_queue', false, false, false, false);
$channel->queue_bind('email_service_queue', 'user_events'); // Привязка очереди к exchange
// Subscriber 2 (Сервис аналитики)
$channel->queue_declare('analytics_queue', false, false, false, false);
$channel->queue_bind('analytics_queue', 'user_events');
// Оба сервиса получат одинаковое сообщение.Преимущества fanout:
- Слабая связанность: Издатель не знает о существовании или количестве получателей.
- Масштабируемость: Новые подписчики добавляются без изменений кода издателя.
- Параллельная обработка: Разные сервисы обрабатывают одно событие независимо и параллельно.
Где используется: Уведомления, логирование в несколько мест, обновления кэша, event-driven архитектура.
Ответ 18+ 🔞
А, фанаут! Ну это ж классика, ебать мои старые костыли. Представь себе такую картину: ты крикнул что-то в толпу, а там куча ушей навострилось, и каждый услышал твой вопль. Вот это и есть fanout, или, как умники говорят, «веерная рассылка». Основа всей этой вашей модели «публикуй-подписывайся».
Как эта штука работает, если на пальцах:
- Отправитель (Publisher) не тыкает сообщение прямо в какую-то одну очередь, как дурак. Он выходит на трибуну, в так называемый exchange (или топик), и орет туда своё слово.
- Exchange типа fanout — это такой весёлый тип, которому похуй на любые ключи и правила. Его девиз: «Всем сестрам по серьгам!». Он тупо копирует полученное сообщение и суёт его во все очереди, которые к нему привязаны.
- Каждый Подписчик (Subscriber), который сидит у своей личной очереди и ждёт у моря погоды, получает свою собственную, полную копию этого сообщения. Все довольны.
Где это вкатывают в PHP-приложениях? Да везде! Ну, например, пользователь зарегистрировался. Событие UserRegistered летит в эфир, а там его уже ловят: сервис отправки приветственного письма, сервис аналитики, который считает новых лохов, сервис рекомендаций, который сразу начинает думать, какую хуйню этому пользователю впарить. Всё параллельно, все счастливы.
// Тот, кто орет (Publisher). Библиотека php-amqplib.
$connection = new AMQPStreamConnection('rabbitmq', 5672, 'guest', 'guest');
$channel = $connection->channel();
// Объявляем exchange типа 'fanout' с именем 'user_events'. Это наша трибуна.
$channel->exchange_declare('user_events', 'fanout', false, false, false);
$eventData = json_encode(['user_id' => 123, 'email' => 'user@example.com']);
$msg = new AMQPMessage($eventData);
// Публикуем сообщение в exchange. Ключ маршрутизации (routing_key) можно не указывать — fanout на него всё равно забил болт.
$channel->basic_publish($msg, 'user_events');
// А вот Подписчик 1 (Сервис отправки email). Он создал свою очередь.
$channel->queue_declare('email_service_queue', false, false, false, false);
// И привязал её к нашей трибуне 'user_events'. Теперь он в теме.
$channel->queue_bind('email_service_queue', 'user_events');
// Подписчик 2 (Сервис аналитики). То же самое, своя очередь.
$channel->queue_declare('analytics_queue', false, false, false, false);
$channel->queue_bind('analytics_queue', 'user_events');
// И оба этих сервиса получат по одинаковой копии сообщения. Ёперный театр, красота!Чем это всё охуенно:
- Связи почти нет: Тот, кто орет, вообще не в курсе, кто его слушает и слушает ли кто-то вообще. Доверия ебать ноль, и это хорошо.
- Масштабируется просто: Захотел добавить новый сервис, который слушает регистрации? Просто создай ему очередь и привяжи к тому же exchange. Код того, кто орет, менять не надо — он уже всё сделал.
- Всё параллельно: Письмо отправляется, аналитика пишется, кэш обновляется — всё одновременно, не мешая друг другу.
Короче, где применяют: Да везде, где одно событие должно запустить кучу независимых процессов. Уведомления, логирование в несколько мест, обновления всякого говна, event-driven архитектура — везде этот fanout кочует. Удобная, бля, штука.
