Комментарии 10
Разумно. Если критично время, то вредно под запрос устанавливать соединение.
(у нас один разработчик смог даже на REST Proxy каждый раз устанавливать соединение)
Кстати, а почему Kafka, если важно время? Она вроде сильно хуже RabbitMQ по таймингам?
А что делает RabbitMQ для PHP родным? Для него кстати тоже есть такой прокси cloudamqp/amqproxy.
php - умеет держать persistent connection по amqp протоколу, а с Kafka - такого пока не придумали.
В целом, написал так потому что, практически все проекты о которых я слышал, используют именно RabbitMQ, в том числе туториалы для начинающих также описывают работу с очередями на базе RabbitMQ.
RabbitMQ использует протокол amqp - который также является достаточно затратным для установки соединения, но на моей практике - проблем это не вызывало.
С RabbitMQ начинаются проблемы, когда начинается работа с 10+к сообщений в секунду или же когда хочется большие сообщения пересылать(500kb+).
Если память не изменяет, Slack использует Go для подобного решения. Go держит соединение с кафкой и принимает http запросы от PHP
Действительно, есть огромный соблазн использовать самописную прокси, написанную за полчаса на Гошке, которая жрёт оперативки в 100 раз меньше, но мы пока что не имели возможности выделить времени на тестирование стабильности работы такого решения в продакшене.
Можно еще librdkafka с https://github.com/arnaud-lb/php-rdkafka глянуть. Решает проблему поднятия соединения.
Спасибо, интересный подход. На своем беке какая ось стоит?
Посмотрите в сторону NATS / Jetstream.
PHP & Kafka — production sadness