Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Цвет подобран прекрасно. Намекает…
О чём статья? Что вы написали 3 строчки на PHP в роли демона для логгера, который не умирает, тем самым нарушая главный принцип PHP? Или что вы, опять же, при обработке запросов, куда-то коннектитесь через сокеты, обёрнутые ещё несколькими слоями, чтобы отправить лог? При чём здесь многопоточность? При чём здесь PHP в принципе? Или вы хотели рассказать про IPC для PHP, что само по себе абсурдно, опять же, из-за парадигмы недолгоживущих процессов php?
Ваш главный принцип «PHP должен умирать»? Это нормально с этим можно продолжать жить.
Пора выйти из танка и оглянуться вокруг.
PHP уже с 5.3 прекрасно работает как долгоживущий процесс. А с выходом PHP 7, появиться возможность не падать при фатальных ошибках и проблем с долгой жизнью процессов не останется вовсе.
PHP уже с 5.3 прекрасно работает как долгоживущий процесс. А с выходом PHP 7, появиться возможность не падать при фатальных ошибках и проблем с долгой жизнью процессов не останется вовсе.
Демон упал — можно подстраховать через upstart.
Я недоумевал ни сколько из-за того, что PHP не должен жить, а из-за того, что человек написал статью как установить 0MQ, биндинги в PHP и написать 3 строчки кода, сделав демона логгера на этом самом PHP, хотя эти три строчки демона можно было написать на чем-то более подходящем, без установки биндингов и веб-серверов, например. Посередине статьи автор заикнулся про свой набор паттернов, не написав зачем и почему и куда.
уже сейчас можно не падать при фатальных ошибках, по крайней мере можно сделать свой обработчик и при большом желании возвращать управление из него основному процессу.
Как то большего ожидал от поста, надеялся увидеь Akka на php что-ли…
Однажды сталкивался с подобной задачей, пришел к выводу, что redis pub/sub подходит лучше. Заодно в редисе таски создавать можно и логи вести через monolog. И расширение компилить не надо — php-redis ставится из пакетов.
Этот вариант хорош, хотя в некоторых случаях имеет концептуальные проблемы. К примеру, если у вас несколько нод, то сообщения будут всегда рассылаться на все ноды, даже если одна из них, к примеру, никак не участвует. Кроме этого, в некоторых случаях следует быть осторожным, если у вас множество каналов — сложность publish растет O(n+m). Третьим моментом может быть то, что подписка требует выделенного соединения и не может использовать уже существующее (например, приложение использует редис для хранения каких-то данных). Ну и данные не сохраняются, поэтому схема в таком виде может применяться только если есть хоть один читатель (или эмулировать через другие команды для персистентной очереди)
Вместе с этим, Redis pub/sub очень легкое и хорошее решение, использую сам в продакшине уже несколько лет, только позитивные впечатления.
Вместе с этим, Redis pub/sub очень легкое и хорошее решение, использую сам в продакшине уже несколько лет, только позитивные впечатления.
ZeroMQ достаточно хорошая вещь, но это все равно реализация AMQP, всего лишь за исключением нескольких плюшек.
Если же говорить о AMQP, а именно о этом подходе, то здесь наверное для простых задач и кролик справиться на 5+, учитывая, что из-за exchange (точка обмена, что Вы «обосрали»), есть куча разных возможностей, в том числе и обработка одного и того же сообщениями разными воркерами.
Также, следует посмотреть в сторону Gearman, у него большая плюшка в том, что можно просмотреть статус выполнения задачи, что очень даже не хватает.
Откуда Вы это взяли? Посмотрите сколько форков и звезд на репе реакта (не так то и много, но и не мало, чтобы не дать этому уважение).
P.S. В общем, ожидал от статьи больше. Это как на конфах часто видно название доклада «Ассинхроность в PHP», а начинают рассказывать там о разных RabbitMQ, ActiveMQ, etc…
Если же говорить о AMQP, а именно о этом подходе, то здесь наверное для простых задач и кролик справиться на 5+, учитывая, что из-за exchange (точка обмена, что Вы «обосрали»), есть куча разных возможностей, в том числе и обработка одного и того же сообщениями разными воркерами.
Также, следует посмотреть в сторону Gearman, у него большая плюшка в том, что можно просмотреть статус выполнения задачи, что очень даже не хватает.
Сначала ты оптимизируешь код, потом пытаешься изменить сознание на асинхронный реакт, но весь PHP мир не хочет понимать такое стремление.
Откуда Вы это взяли? Посмотрите сколько форков и звезд на репе реакта (не так то и много, но и не мало, чтобы не дать этому уважение).
P.S. В общем, ожидал от статьи больше. Это как на конфах часто видно название доклада «Ассинхроность в PHP», а начинают рассказывать там о разных RabbitMQ, ActiveMQ, etc…
ZeroMQ — это реализация AMQP? o_O
Да, уж, сорри, ошибочка, сам не знал.
zeromq.wdfiles.com/local--files/intro%3Aread-the-manual/Middleware%20Trends%20and%20Market%20Leaders%202011.pdf
Указано, что они хотели бы его поддерживать, но он сильно громоздкой, по их мнению, и пока что они решили его не внедрять. Но опять же, документ датирован 2011 года (http://zeromq.org/intro:read-the-manual Comparisons)
Да, они не используют этот протокол, но методология (pattern) один и тот же.
zeromq.wdfiles.com/local--files/intro%3Aread-the-manual/Middleware%20Trends%20and%20Market%20Leaders%202011.pdf
Указано, что они хотели бы его поддерживать, но он сильно громоздкой, по их мнению, и пока что они решили его не внедрять. Но опять же, документ датирован 2011 года (http://zeromq.org/intro:read-the-manual Comparisons)
Да, они не используют этот протокол, но методология (pattern) один и тот же.
Мне было не очень понятно, почему ZeroMQ попал в один список с
RabbitMQ, ActiveMQ, Kafka, Kestrel и даже Redis.. Ведь ZeroMQ — это, как вы правильно заметили, только лишь «набор сокетов на стероидах». Как же его можно сравнивать с Kafka, скажем или с RabbitMQ…
Самый большой вопрос в данном случае что происходит когда демон умирает или связь затыкается. Такая простая реализация на коленке конечно будет работать, но в реальности нужно делать heartbeat, продумывать и реализовывать свой протокол с обработкой ошибок, обработкой дубликатов, ресабмит данных в очередь, шардинг тасков через воркеры динамически и т.д. Реальность достаточно сложная штука, еще следить за тем как закрываются и обрабатываются соединения в самом php и избегать блокировки ресурсов или снова наворачивать еще микро-очереди-сервисы для блокирующих операций.
Крайне рекомендую посмотреть доклад Алексея Качаева про ZeroMQ для того чтоб понять что все это далеко не так просто как написать 3 строчки кода и что люди используют готовые сервера очередей не просто так: www.youtube.com/watch?v=d26LufnoQ4I
Крайне рекомендую посмотреть доклад Алексея Качаева про ZeroMQ для того чтоб понять что все это далеко не так просто как написать 3 строчки кода и что люди используют готовые сервера очередей не просто так: www.youtube.com/watch?v=d26LufnoQ4I
Все верно в примере с генератором и воркерами есть и хертбиты и проверка статусов, как генератора так и воркера с отслеживанием переходов из одного в другой и стратегия для реконнектов Но, как я писал выше, вся ентерпрайзность пишется руками и под конкретную задачу. Где-то можно пропускать месседжы, где-то нужно биться до последнего, где-то нужны синхронизации и транзакции. Все эти вещи определяются задачей, которую нужно решать. Увы такое не решается в общем виде.
Да доклад отличный в нем нет противоречий моим словам.
Да доклад отличный в нем нет противоречий моим словам.
Для асинхронных задач есть nodejs, Java, phpDemon… Так извращаться можно только если проект уже есть и он большой, и переписывать его лень.
ЗЫ, сам люблю PHP. Автору спасибо, библиотеку посмотрю.
ЗЫ, сам люблю PHP. Автору спасибо, библиотеку посмотрю.
Друг, мне кажется, ты хочешь сделать из php то, чем он не является. Попробуй erlang. Выглядит так, как будто ты хочешь писать код именно в его стиле.
Если же ты хотел познакомить аудиторию с ZeroMQ, то выбрал весьма неудачный способ. 0MQ — решение для узкого круга задач, когда нам не нужна гарантия выполнения, не нужны очереди (или мы готовы писать эти вещи сами). Зачем они вообще нужны? Вот хорошее описание (раздел ack).
Строить на 0MQ асинхронный php фреймворк? Во-первых, асинхронные фреймворки есть, и они работают. Во-вторых, есть hack. Предлагаю посмотреть на его реализацию асинхронности и прикинуть – может это именно то, что нужно? Набор хороших библиотек, и, я уверен, код на hack будет так же сексуален, как генераторы на node.js (описание проблемы управления flow в event-driven programming, библиотека (внимание на yield)).
Можно спросить, «а где тут взаимодействие между серверами на php?». Можно написать самому. А можно использовать какой-нибудь *MQ с очередями.
Если же ты хотел познакомить аудиторию с 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-шный демон оформлен ввиде службы, а на линухе ввиде сервиса.
Чуть позже было принято решение докрутить туда ещё и аналог крона, для единой точки управления отложенных задач и «параллельных» долгих вычислений.
Ну а обработать нужно сейчас, а не через время, так что крон и отложенная задача отпала. Смотрели в сторону MQ систем, да, решения есть, но нас они целиком не устроили. Решили писать своего Queue-шного демона на QT, который по своему протоколу ждёт команду с дальнейшими указаниями, что ему делать дальше. После получения запроса из веба (мы на yii пишем) мы обрабатываемых запрос и все критические данные сохраняем, а после делаем обращение к нашей очереди (которая при необходимости умеет агрегировать запросы, если это разрешается по протоколу) и спокойно завершаем процесс. Очередь же осуществляет новый запрос к серверу для «продолжения» прошлого запроса и обработки долгих операций (а операции реально долгие).
Вся эта кухня предоставляется как инхостовое решение под windows, или как облочное решение (saas) в амазоне.
На винде queue-шный демон оформлен ввиде службы, а на линухе ввиде сервиса.
Чуть позже было принято решение докрутить туда ещё и аналог крона, для единой точки управления отложенных задач и «параллельных» долгих вычислений.
Настанет день, и это случится.
Сначала ты читаешь первые пару абзацев и замечаешь удивительное сходство речевых оборотов автора и одного из твоих знакомых программистов. «Хех, прикольно» — думаешь ты. Дочитав до середины статьи, ты уже не на шутку удивлён сходством не только оборотов, но и манеры изложения. «Возможно, это особый стиль общения в какой-то тусовочке» — строишь ты предположение. Затем ты дочитываешь до конца и решаешь всё-таки узнать, кто же этот автор, что его манера разговора настолько популярна…
P.S. Димону привет передавай. =)
Сначала ты читаешь первые пару абзацев и замечаешь удивительное сходство речевых оборотов автора и одного из твоих знакомых программистов. «Хех, прикольно» — думаешь ты. Дочитав до середины статьи, ты уже не на шутку удивлён сходством не только оборотов, но и манеры изложения. «Возможно, это особый стиль общения в какой-то тусовочке» — строишь ты предположение. Затем ты дочитываешь до конца и решаешь всё-таки узнать, кто же этот автор, что его манера разговора настолько популярна…
P.S. Димону привет передавай. =)
В 99% для подобных задач достаточно трёх компонентов:
— worker.php
— supervisord (или другой менеджер процесов) который запускает worker`ы в нужном количестве(хоть 1, хоть 100) и перезапускает при падении или плановом exit(0) через 10к итераций(на всякий случай, хоть и как уже сказали без этого можно обойтись)
— очередь (хоть файловая с изъятием в очередь конкретного воркера средствами mv, хоть rabbitmq, хоть mysql табличка с правильной логикой блокировок).
Каждый из трёх можно менять по вкусу (для меня главный критерий — maintainability, в т.ч. не усложнять систему без необходимости).
Для задач, где таск длится более 5 секунд эта комбинация показала себя как самая управляемая.
Если таск 1-3 секунды тоже ОК, но файловая очередь поменяна на кролика и/или mysql
Если менее секунды, то да, нужен сервер очередей.
— worker.php
— supervisord (или другой менеджер процесов) который запускает worker`ы в нужном количестве(хоть 1, хоть 100) и перезапускает при падении или плановом exit(0) через 10к итераций(на всякий случай, хоть и как уже сказали без этого можно обойтись)
— очередь (хоть файловая с изъятием в очередь конкретного воркера средствами mv, хоть rabbitmq, хоть mysql табличка с правильной логикой блокировок).
Каждый из трёх можно менять по вкусу (для меня главный критерий — maintainability, в т.ч. не усложнять систему без необходимости).
Для задач, где таск длится более 5 секунд эта комбинация показала себя как самая управляемая.
Если таск 1-3 секунды тоже ОК, но файловая очередь поменяна на кролика и/или mysql
Если менее секунды, то да, нужен сервер очередей.
Ааа, я думал так с supervisord только я извращаюсь
У нас таким образом организована синхронизация из кэша некритичных данных в основную БД. Используем redis SET для того, чтобы контроллировать уникальность сообщений в очереди. Сообщение — id записи, которую надо отправить в БД. Вот думаем, как более красиво можно решить данный момент.
У нас таким образом организована синхронизация из кэша некритичных данных в основную БД. Используем redis SET для того, чтобы контроллировать уникальность сообщений в очереди. Сообщение — id записи, которую надо отправить в БД. Вот думаем, как более красиво можно решить данный момент.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размазываем PHP