Приятно общаться с HR, когда у не "шаблонный подход". Очень забавляли HR, которые сначала присылали тестовое, а потом после решения типо пообщаемся и расскажем о компании. Такие сразу в блок. Зачем мне тратить время на тех, кто даже не удосужился рассказать, кто они, про что они и зачем мне вообще на них тратить время и т.д.
Вся суть статьи автора, сводится к тому, что не нужно использовать Stateless JWT. Берешь Stateful JWT и почти все проблемы исчезают.... Зачем брать, что-то плохое, если об этом заранее известно, когда есть решения лучше.
там речь была не про то, чтобы понять работает сам сервис или нет, в приле может быть ошибка и бизнес-логика перестанет работать как это задумывалось, а сам сервис будет работать дальше. Поэтому, далее и обсуждали варианты того, что должно быть что-то, что позволяет контролировать что свыполнением бизнес-логики все ОК, а не работой самого сервиса.
+ сам systemd (лично у меня, ну и от коллег слышал), часто плодит зомби процессы, при том что используются сигналы обработки
"А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке " - судя по всему никак.
"Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов " - в своей системе по аналогии с вашей делал сквозное событие и проверку итогового значения, последнее событие должно пройти все инстанции(сокеты, кафку, обработчик и записать в таблицу), там уже смотрел, той-же кумой, что если время последней записи не более N минут, значит система жива.
1. Чем это решение(SIGALRM) принципиально лучше, того-же супервизора и любых +- подобных систем? - по этому вопросу не много не так написал, не чем лучше супервизора и т.д, а для данного воркера его же в любом случае придется также запускать через супервизор, php script.php, системд и т.д, в чем отличие тогда - "Без всяких "супервизоров, роадраннеров и свулов". "
ну как я понял, SIGNALRM дает возможность менее нагружать систему используя тики, если сравнивать в бесконечным циклом, но pcntl_alarm() вставляет паузы в обработку, что не для всех типов воркеров подходит(так как замедляет обработку) + " записывает идентификатор процесса и прогресс работы." - если я правильно понял, то это то-же доп. событие той-же кафки (я про свой пример), которое обрабатывается как штатное задание для воркера и добавляет в некий журнал и говорит нам, что обработчик работает(своего рода healthcheck), если записи нет, то значит у нас проблема.
>>> Есть некоторые вопросы:
1. Чем это решение(SIGALRM) принципиально лучше, того-же супервизора и любых +- подобных систем?
2. Пока что кажется, что данное решение оптимально для каких-то фоновых обработок, не требующих высокого уровня надежности и допускающих определенный простой в случае проблемы(например, синхронизация товаров с 1С, рассылка писем и еще что-то),
Допустим у меня система тестирования, которая работает на событиях от кафки (отдельный плеер от бекенда на react через веб-сокеты шлет сообщения на сервер Nodejs, далее данные пересылаются в журналы kafa, далее обработчик на PHP должен это все обработать и добавить записи в другой журнал кафки и все возвращается обратно в плеер)
Допустим 500 человек проходит тестирование и воркер завис, и все пропало почти(перезапустить тест нельзя, обратной связи никто не получит(и не должен, так как система подразумевает, что все должно работать в штатном режиме и с 1-го раза)
Для такой системы подобное решение не выглядит оптимальным, поправьте, если ошибаюсь...?
поделитесь вариантом решения? если не секрет конечно(это не сарказм, не спор), просто интересно. Желательно, чтобы можно было мониторить состояние сервиса(жив, он мертв или завис) и удобно перезапускать его, при этом не бороться со всякими зомби процессами.
"Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий" - например, как вариант, сделать на PHP демона (или полноценное приложение реалтаймовое), который будет читать сообщения из кафки или работать с вебсокетами напрямую и при это так-же стабильно работать, может быть проблематично или практически не реально (понятное дело, что есть супервизиры, системд, роадранеры, свулы и т.д), но на node, go это из коробки и стабильно, а PHP для этого не предназначен. Я хоть и пишу на PHP, но отрицать, что у других ЯП, есть определенные преимущества перед ним, весьма сомнительно.
FrontPage - вообще пушка, свой первый сайт сделал в нем еще в школе и хостил на народе...
Приятно общаться с HR, когда у не "шаблонный подход".
Очень забавляли HR, которые сначала присылали тестовое, а потом после решения типо пообщаемся и расскажем о компании. Такие сразу в блок. Зачем мне тратить время на тех, кто даже не удосужился рассказать, кто они, про что они и зачем мне вообще на них тратить время и т.д.
Вся суть статьи автора, сводится к тому, что не нужно использовать Stateless JWT. Берешь Stateful JWT и почти все проблемы исчезают.... Зачем брать, что-то плохое, если об этом заранее известно, когда есть решения лучше.
там речь была не про то, чтобы понять работает сам сервис или нет, в приле может быть ошибка и бизнес-логика перестанет работать как это задумывалось, а сам сервис будет работать дальше. Поэтому, далее и обсуждали варианты того, что должно быть что-то, что позволяет контролировать что свыполнением бизнес-логики все ОК, а не работой самого сервиса.
+ сам systemd (лично у меня, ну и от коллег слышал), часто плодит зомби процессы, при том что используются сигналы обработки
понял, спасибо за инфу
"А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке " - судя по всему никак.
"Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов " - в своей системе по аналогии с вашей делал сквозное событие и проверку итогового значения, последнее событие должно пройти все инстанции(сокеты, кафку, обработчик и записать в таблицу), там уже смотрел, той-же кумой, что если время последней записи не более N минут, значит система жива.
1. Чем это решение(SIGALRM) принципиально лучше, того-же супервизора и любых +- подобных систем? - по этому вопросу не много не так написал, не чем лучше супервизора и т.д, а для данного воркера его же в любом случае придется также запускать через супервизор, php script.php, системд и т.д, в чем отличие тогда - "Без всяких "супервизоров, роадраннеров и свулов". "
ну как я понял, SIGNALRM дает возможность менее нагружать систему используя тики, если сравнивать в бесконечным циклом, но pcntl_alarm() вставляет паузы в обработку, что не для всех типов воркеров подходит(так как замедляет обработку) + " записывает идентификатор процесса и прогресс работы." - если я правильно понял, то это то-же доп. событие той-же кафки (я про свой пример), которое обрабатывается как штатное задание для воркера и добавляет в некий журнал и говорит нам, что обработчик работает(своего рода healthcheck), если записи нет, то значит у нас проблема.
>>> Есть некоторые вопросы:
1. Чем это решение(SIGALRM) принципиально лучше, того-же супервизора и любых +- подобных систем?
2. Пока что кажется, что данное решение оптимально для каких-то фоновых обработок, не требующих высокого уровня надежности и допускающих определенный простой в случае проблемы(например, синхронизация товаров с 1С, рассылка писем и еще что-то),
Допустим у меня система тестирования, которая работает на событиях от кафки (отдельный плеер от бекенда на react через веб-сокеты шлет сообщения на сервер Nodejs, далее данные пересылаются в журналы kafa, далее обработчик на PHP должен это все обработать и добавить записи в другой журнал кафки и все возвращается обратно в плеер)
Допустим 500 человек проходит тестирование и воркер завис, и все пропало почти(перезапустить тест нельзя, обратной связи никто не получит(и не должен, так как система подразумевает, что все должно работать в штатном режиме и с 1-го раза)
Для такой системы подобное решение не выглядит оптимальным, поправьте, если ошибаюсь...?
поделитесь вариантом решения? если не секрет конечно(это не сарказм, не спор), просто интересно. Желательно, чтобы можно было мониторить состояние сервиса(жив, он мертв или завис) и удобно перезапускать его, при этом не бороться со всякими зомби процессами.
"Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий" - например, как вариант, сделать на PHP демона (или полноценное приложение реалтаймовое), который будет читать сообщения из кафки или работать с вебсокетами напрямую и при это так-же стабильно работать, может быть проблематично или практически не реально (понятное дело, что есть супервизиры, системд, роадранеры, свулы и т.д), но на node, go это из коробки и стабильно, а PHP для этого не предназначен. Я хоть и пишу на PHP, но отрицать, что у других ЯП, есть определенные преимущества перед ним, весьма сомнительно.