Черги й брокери: Redis, RabbitMQ, Kafka та що ще на ринку

Слово «черга» часто ховає різні задачі: відкласти джобу на воркер, розвести повідомлення між сервісами або зберігати стрічку подій, яку читають кілька незалежних команд. Laravel чудово закриває перший сценарій через Redis і Horizon. RabbitMQ зручний, коли важлива маршрутизація та dead letter. Kafka — коли потрібні retention, replay і великий fan-out. Нижче — порівняння, інші продукти, застосування в інших фреймворках і моменти, де технологія занадто важка.

Пов’язані матеріали: Потоки подій під навантаженням · Sail: черги та RabbitMQ

Зміст

Три різні питання до «черги»

Фонова робота — «зроби пізніше»: лист, PDF, зовнішній API. Потрібні retry, таймаути, таблиця failed_jobs, спостереження за воркерами.

Брокер на кшталт Rabbit — ви публікуєте в exchange, повідомлення потрапляють у черги за правилами binding; різні сервіси підписані на різні потоки. Це вже шина між сервісами, не лише відкладений PHP.

Журнал Kafka — партиції, offset, retention. Кілька груп споживачів читають одну тему незалежно. Сильна сторона — історія і повторне читання; слабка — якщо вам треба лише «раз на годину почистити tmp».

Плутанина моделей коштує грошей: Kafka «як одна черга без збереження» або Rabbit «як вічний архів» — завжди компроміси.

Redis у світі Laravel

QUEUE_CONNECTION=redis і Horizon — типовий продакшен для багатьох проєктів: швидко, узгоджено з кешем і лімітами.

Плюси: низька затримка, зрозумілий деплой, готовий UI для воркерів.

Нюанси: пам’ять під піками, eviction, які не повинні з’їдати ключі черг; персистентність Redis ≠ гарантії великого розподіленого логу без явної реплікації та тестів відмов.

Redis Streams — для груп споживачів і стрімінгу; стандартна черга джоб у Laravel орієнтована на задачі, а не на багатоденний immutable архів.

RabbitMQ: маршрути AMQP

AMQP: exchange, черги, binding, TTL, dead-letter. У Laravel — через пакети на кшталт vladimir-yuldashev/laravel-queue-rabbitmq. Зручно поєднувати з Symfony Messenger або поліглотними мікросервісами.

Плюси: гнучка маршрутизація, зрілі патерни експлуатації.

Нюанси: кластер, watermark пам’яті/диска, prefetch — повільний консумер може закупорити видачу. Якщо один моноліт і лише джоби без шини — Rabbit інколи зайвий порівняно з Redis.

Kafka — не поштова скринька

Теми, партиції, offset, retention. Продюсери дописують; споживачі читають з позиції; rebalancing груп — частина життя.

Плюси: великий throughput, багато читачів однієї історії, replay, екосистема стрім-процесингу.

Нюанси: у Laravel немає такого ж «рідного» драйвера, як для Redis; часто окремі консьюмери та бібліотеки. Операції: KRaft, розмір партицій, еволюція схем. Одна Kafka «для рідкісних джоб» — типовий оверінжиніринг.

Інші гравці ринку

  • AWS SQS / SNS — керовані черги та pub/sub; у Laravel є sqs. Увага до visibility timeout і вартості.
  • Google Pub/Sub, Azure Service Bus — хмарні брокери з інтеграцією в IAM і serverless.
  • NATS / JetStream — легкий брокер; JetStream додає персистентність.
  • Beanstalkd — мінімалістичні «труби».
  • Керований Kafka — менше залізничних клопотів, не менше відповідальності за дизайн топиків.

Laravel: драйвери

sync, database, redis, sqs, Rabbit (пакет). Для будь-якого транспорту варто проєктувати ідемпотентність обробки — мережа повторює запити, retry дублює побічні ефекти.

Інші фреймворки

Symfony Messenger, Django + Celery, Node BullMQ / amqplib, Spring, .NET MassTransit — усі підключаються до тих самих Redis/Rabbit/Kafka, якщо узгодити формат повідомлень і версії.

Коли це занадто

Малий трафік — database або Redis без Kafka «на виріст». Один Laravel без міжсервісної шини — Rabbit не за замовчуванням. Величезний потік подій і багато читачів — Kafka або керований стрім, а не одна Redis-list без моніторингу.

Доставка, порядок, отруєні повідомлення

Exactly-once коштує дорого; реалістично — at-least-once + ідемпотентність. У Kafka порядок — у межах партиції. Отруєні повідомлення — ліміт спроб, DLQ, алерти. Метрики: глибина черги, lag, вік найстарішого повідомлення. Зміна схеми без сумісності ламає старих споживачів.

Спочатку сформулюйте: відкладена джоба, маршрутизація між сервісами чи зберігана стрічка подій — і вибір Redis / Rabbit / Kafka стане зрозумілим. Детальніше про дані — потоки подій, про локальний Docker — Sail.