Опашки и брокери: Redis, RabbitMQ, Kafka и какво още има

Думата „опашка“ прикрива различни нужди: да се отложи задача за работник, да се разпределят съобщения между услуги или да се пази непрекъсната лента, която много независими четци консумират с различни темпове. Laravel е особено удобен за първото чрез Redis и Horizon. RabbitMQ влиза в играта при сложна маршрутизация и мъртви писма. Kafka — при голям обем, запазване и повторно възпроизвеждане. По-долу са сравнения, други продукти, примери извън PHP и моментите, в които инструментът е тежък без полза.

Свързани материали: Потоци при високо натоварване · Sail: опашки и RabbitMQ

Съдържание

Три смисъла на „опашка“

Фонова задача — изпрати имейл, генерирай файл, извикай API по-късно. Нужни са повторения, таймаути, failed_jobs, наблюдение на работници.

Брокер (Rabbit) — съобщения минават през exchange към опашки по binding правила; различни услуги слушат различни потоци. Това е интеграционна гръбнака, не само „отложи PHP“.

Kafka журнал — партиции, offset, retention; групи консуматори четат същата тема независимо. Силно за история и нови downstream консуматори; излишно, ако искате само „cron в 3 часа“.

Redis и Laravel

QUEUE_CONNECTION=redis + Horizon е чест сценарий: ниска латентност, споделен Redis с кеш.

Внимание: памет при пикове, eviction, която не трябва да изтрива ключове на опашки; персистентността на Redis не е автоматично същото като географски разпределен лог без явна репликация и тестове.

Streams са за групи консуматори; стандартната job опашка на Laravel е ориентирана към задачи, не към многодневен архив.

RabbitMQ и AMQP

Exchange, опашки, TTL, dead-letter, prefetch. В Laravel — чрез пакети като vladimir-yuldashev/laravel-queue-rabbitmq. Добър съсед на Symfony Messenger и полиглотни услуги.

Оперативна цена: клъстер, прагове за памет/диск, настройка на prefetch — бавен консуматор може да задръсти доставката. Един монолит само с джобове често се справя с Redis без Rabbit.

Kafka като дневник

Теми, партиции, offset, rebalancing на групи. Огромен throughput при добро партициониране; много четци на една история; replay.

Laravel няма вграден драйвер на равнище на Redis; често отделни консьюмери и клиентски библиотеки. Ops: KRaft, размер на партиции, схеми. Kafka само за редки джобове — често грешка по мащаб.

Пазар извън триото

SQS/SNS, Pub/Sub, Service Bus — управлявани услуги; Laravel има sqs. NATS/JetStream — лек брокер. Beanstalkd — минимализъм. Managed Kafka — по-малко железо, същият дизайн на теми.

Драйвери в Laravel

sync, database, redis, sqs, Rabbit (пакет). Идемпотентност на обработчиците — задължителна мисъл при at-least-once и мрежови повтори.

Други екосистеми

Symfony Messenger, Django/Celery, BullMQ, Spring, MassTransit — общите брокери работят, ако форматът на съобщенията е договорен.

Кога е прекалено

Малък трафик — database/Redis, не Kafka „за бъдеще“. Няма междусервизна шина — Rabbit не е задължителен. Огромен поток и много четци — Kafka или управляван поток, не една Redis list без аларми.

Остри ъгли

Exactly-once е скъпо; at-least-once + идемпотентност — реалистично. Редът в Kafka е в партиция. Отровни съобщения — лимит опити, DLQ, paging. Метрики: дълбочина, lag, възраст на най-старото съобщение. Промяна на схемата чупи стари консуматори.

Резюме: определете дали ви трябва отложена работа, маршрутизирана шина или запазен лог — и чак тогава изберете Redis, Rabbit или Kafka. За данни вижте high-load събития, за локален Docker — Sail.