borisd_ru 12 янв 2020 в 01:28

Перевод PHP бэкенда на шину Redis streams и выбор независимой от фреймворков библиотеки

7 мин

9.1K

PHP*Symfony*Распределённые системы*DIY или Сделай сам

Туториал

+12

Комментарии 12

OleksiyT 12 янв 2020 в 08:13

Если задача уйти от фреймворка, то для простого многопоточного парсера стандартных библиотек php разве недостаточно?

Использование лишних и слабо документированных вещей — так себе решение. Уж лучше фреймворк тогда, я считаю )

borisd_ru 12 янв 2020 в 11:40

Ну нет, от фреймворка уйти нет задачи, а иногда есть задача искать компоненты, не привязанные к определенным фреймворкам. В моём проекте в качестве «фреймворка» используется, грубо говоря, контейнер и request-router, а остальное — компоненты.

shm-vadim 12 янв 2020 в 08:18

Здесь смотрели? У симфони документация по компонентам и по их использованию в рамках фреймворка располагается отдельно.

borisd_ru 12 янв 2020 в 11:35

В конечном итоге, конечно, да, и на этой странице хорошее пояснение с примером на PHP, но на странице о транспорте из Learn more есть примеры только на yml или контейнере симфони.

voodooism 12 янв 2020 в 11:40

На самом деле, гораздо лучше будет полностью сконгфигурировать компонент symfony/messenger в контейнере и инжектить интерфейс MessageBusInterface в контроллер.

Кстати, в самом компоненте symfony/messenger уже реализованы несколько полезных команд, включая запуск воркеров. Так что, вместо того, что бы писать свой запуск воркера можно подключить компонент symfony/console и использовать уже имеющийся в компоненте функционал.

borisd_ru 12 янв 2020 в 11:42

Надо будет посмотреть — как раз этот symfony/console затянулся с зависимостями. Хотя я искал использование интерфейсов MessageBus (и прочих) в vendor и не помню, чтоб встретил что-то подходящее.

Bonio 12 янв 2020 в 13:33

Я с symfony/messenger так и не разобрался, по моему он излишне усложнён. Хотя в моём случае все решилось гораздо проще и вообще без использования сторонних компонентов.

В приложении добавляем сообщения в очередь методом rPush:

/*
    Code logic
*/

$redis = new Redis();
$redis->rPush("message_queue", "message 1");

А в воркере-обработчике делаем вот так:

$redis = new Redis();
$redis->setOption(Redis::OPT_READ_TIMEOUT, -1);

while(true) {
    list($queue, $message) = $redis->blPop(["message_queue"], 0);
    /*
        Logic to processing $message
    */
}

while тут не выполняется бесконечно, а приостанавливается на blPop в ожидании сообщения.

borisd_ru 12 янв 2020 в 14:59

Если такой подход решает задачу — то вполне норм. Но messenger дает гибкость, ценой создания непонятных абстракций. В принципе, как я и писал выше — я сделал демо по работе с мессенджером с redis streams, состоящий из всего нескольких файлов без всякой лишней мишуры и зависимостей: github.com/backend-university/products/tree/master/products/02-redis-streams-bus.
Может быть будет полезно.

SergeyRogulin 13 янв 2020 в 12:15

Прекрасный у Вас пример получился. Единственное, перечень используемых в системе сообщений «размазан» по нескольким слоям: упоминания встречаются как непосредственно в примерах (в consumer`ах), так и в конфигурации сервисов (config/container.php).

Вот если бы добавить функцию авторегистрации всех доступных сообщений в контейнер…

borisd_ru 13 янв 2020 в 12:20

Да, там надо роутинг продумать, есть проблемы с «наивным» подходом, например, если поставить "*" в качестве ключа, то тогда нужно будет настраивать group/consumer в коннектах к стримам, иначе консьюмеры будет получать чужие сообщения и делать «nack», удаляя их из стрима (это уже часть реализации messenger).
Думал упомянуть этот в статье, но показалось, что она и так уже растянулась.