я правильно понимаю, если у меня там крутится apache, пару докеров на разных портах я "перед ними" еще просто ставлю ngnix в режиме реверс-прокси и уже он раскидывате?
почитаю. спасибо!
когда задачи по факту выполнены, но весь процесс остановится, так как счетчик не заполнится полностью.
я так понимаю это не вариант, т.к. в очереди могут быть задачи из другой новой группы
Это понятно, но и воркер должен работать так, что при повторной обработке задачи не было проблем.
Если поставим инкрементацию кол-ва выполненных до финализации задачи в очереди, то при сбоях в воркере (если он упал после инкрементации, но до финализации задачи) кол-во выполненных может быть больше реального кол-ва задач, некрасиво, но работу не нарушит.
Т.е. повторное выполнение той же самой задачи воркером никак не должно нам мешать.
Главное проработать возможные ошибки, если воркер вылетел на середине задачи, а затем начал ее сначала.
обычно цена со скидкой высчитывается "на лету"
- $data = stripcslashes($_POST['form']['dataJSON']);
+ echo $_POST['form']['dataJSON']; die();
$dataJS = json_decode($data, true);
echo "res: ".$dataJS['day'];добавление \K стирает то, что не в группе,
Что подразумевается под агрегатными задачами?
Также, из-за того что эти задания не предназначены определенному воркеру, то один воркер может обработать 2 задания-стопера
В варианте с заданием-стопером вы создаете зависимость между брокером и воркерами, брокер должен всегда точно знать сколько работает воркеров.
Или, например, некий менеджер, который будет собирать информацию с воркеров
В моём случае это избыточно, достаточно использовать счётчик.
Решение, бывшее на старте, частично страдало от опыта предыдущего, однопоточного подхода: получил пачку заданий, в цикле обработал, потом подвёл итоги. С появлением параллельной обработки этот опыт стал непригоден, но от инерции мышления избавиться трудно