Размазываем PHP

О чём статья? Что вы написали 3 строчки на PHP в роли демона для логгера, который не умирает, тем самым нарушая главный принцип PHP? Или что вы, опять же, при обработке запросов, куда-то коннектитесь через сокеты, обёрнутые ещё несколькими слоями, чтобы отправить лог? При чём здесь многопоточность? При чём здесь PHP в принципе? Или вы хотели рассказать про IPC для PHP, что само по себе абсурдно, опять же, из-за парадигмы недолгоживущих процессов php?

Как то большего ожидал от поста, надеялся увидеь Akka на php что-ли…

Однажды сталкивался с подобной задачей, пришел к выводу, что redis pub/sub подходит лучше. Заодно в редисе таски создавать можно и логи вести через monolog. И расширение компилить не надо — php-redis ставится из пакетов.

ZeroMQ достаточно хорошая вещь, но это все равно реализация AMQP, всего лишь за исключением нескольких плюшек.
Если же говорить о AMQP, а именно о этом подходе, то здесь наверное для простых задач и кролик справиться на 5+, учитывая, что из-за exchange (точка обмена, что Вы «обосрали»), есть куча разных возможностей, в том числе и обработка одного и того же сообщениями разными воркерами.
Также, следует посмотреть в сторону Gearman, у него большая плюшка в том, что можно просмотреть статус выполнения задачи, что очень даже не хватает.

Сначала ты оптимизируешь код, потом пытаешься изменить сознание на асинхронный реакт, но весь PHP мир не хочет понимать такое стремление.

Откуда Вы это взяли? Посмотрите сколько форков и звезд на репе реакта (не так то и много, но и не мало, чтобы не дать этому уважение).

P.S. В общем, ожидал от статьи больше. Это как на конфах часто видно название доклада «Ассинхроность в PHP», а начинают рассказывать там о разных RabbitMQ, ActiveMQ, etc…

Мне было не очень понятно, почему ZeroMQ попал в один список с

RabbitMQ, ActiveMQ, Kafka, Kestrel и даже Redis.

. Ведь ZeroMQ — это, как вы правильно заметили, только лишь «набор сокетов на стероидах». Как же его можно сравнивать с Kafka, скажем или с RabbitMQ…

Самый большой вопрос в данном случае что происходит когда демон умирает или связь затыкается. Такая простая реализация на коленке конечно будет работать, но в реальности нужно делать heartbeat, продумывать и реализовывать свой протокол с обработкой ошибок, обработкой дубликатов, ресабмит данных в очередь, шардинг тасков через воркеры динамически и т.д. Реальность достаточно сложная штука, еще следить за тем как закрываются и обрабатываются соединения в самом php и избегать блокировки ресурсов или снова наворачивать еще микро-очереди-сервисы для блокирующих операций.
Крайне рекомендую посмотреть доклад Алексея Качаева про ZeroMQ для того чтоб понять что все это далеко не так просто как написать 3 строчки кода и что люди используют готовые сервера очередей не просто так: www.youtube.com/watch?v=d26LufnoQ4I

Для асинхронных задач есть nodejs, Java, phpDemon… Так извращаться можно только если проект уже есть и он большой, и переписывать его лень.

ЗЫ, сам люблю PHP. Автору спасибо, библиотеку посмотрю.

Друг, мне кажется, ты хочешь сделать из php то, чем он не является. Попробуй erlang. Выглядит так, как будто ты хочешь писать код именно в его стиле.
Если же ты хотел познакомить аудиторию с ZeroMQ, то выбрал весьма неудачный способ. 0MQ — решение для узкого круга задач, когда нам не нужна гарантия выполнения, не нужны очереди (или мы готовы писать эти вещи сами). Зачем они вообще нужны? Вот хорошее описание (раздел ack).
Строить на 0MQ асинхронный php фреймворк? Во-первых, асинхронные фреймворки есть, и они работают. Во-вторых, есть hack. Предлагаю посмотреть на его реализацию асинхронности и прикинуть – может это именно то, что нужно? Набор хороших библиотек, и, я уверен, код на hack будет так же сексуален, как генераторы на node.js (описание проблемы управления flow в event-driven programming, библиотека (внимание на yield)).
Можно спросить, «а где тут взаимодействие между серверами на php?». Можно написать самому. А можно использовать какой-нибудь *MQ с очередями.

Столкнулись как-то мы на работе с проблемой, что нужно обрабатывать очень много записей в БД, при простом нажатии на кнопку в UI-е (мы пишем MDM систему).
Ну а обработать нужно сейчас, а не через время, так что крон и отложенная задача отпала. Смотрели в сторону MQ систем, да, решения есть, но нас они целиком не устроили. Решили писать своего Queue-шного демона на QT, который по своему протоколу ждёт команду с дальнейшими указаниями, что ему делать дальше. После получения запроса из веба (мы на yii пишем) мы обрабатываемых запрос и все критические данные сохраняем, а после делаем обращение к нашей очереди (которая при необходимости умеет агрегировать запросы, если это разрешается по протоколу) и спокойно завершаем процесс. Очередь же осуществляет новый запрос к серверу для «продолжения» прошлого запроса и обработки долгих операций (а операции реально долгие).
Вся эта кухня предоставляется как инхостовое решение под windows, или как облочное решение (saas) в амазоне.
На винде queue-шный демон оформлен ввиде службы, а на линухе ввиде сервиса.
Чуть позже было принято решение докрутить туда ещё и аналог крона, для единой точки управления отложенных задач и «параллельных» долгих вычислений.

Настанет день, и это случится.

Сначала ты читаешь первые пару абзацев и замечаешь удивительное сходство речевых оборотов автора и одного из твоих знакомых программистов. «Хех, прикольно» — думаешь ты. Дочитав до середины статьи, ты уже не на шутку удивлён сходством не только оборотов, но и манеры изложения. «Возможно, это особый стиль общения в какой-то тусовочке» — строишь ты предположение. Затем ты дочитываешь до конца и решаешь всё-таки узнать, кто же этот автор, что его манера разговора настолько популярна…



P.S. Димону привет передавай. =)

В 99% для подобных задач достаточно трёх компонентов:
— worker.php
— supervisord (или другой менеджер процесов) который запускает worker`ы в нужном количестве(хоть 1, хоть 100) и перезапускает при падении или плановом exit(0) через 10к итераций(на всякий случай, хоть и как уже сказали без этого можно обойтись)
— очередь (хоть файловая с изъятием в очередь конкретного воркера средствами mv, хоть rabbitmq, хоть mysql табличка с правильной логикой блокировок).

Каждый из трёх можно менять по вкусу (для меня главный критерий — maintainability, в т.ч. не усложнять систему без необходимости).
Для задач, где таск длится более 5 секунд эта комбинация показала себя как самая управляемая.
Если таск 1-3 секунды тоже ОК, но файловая очередь поменяна на кролика и/или mysql
Если менее секунды, то да, нужен сервер очередей.