Я сомневаюсь, зачем мне их использовать, если я могу просто опросить базу данных и получить самую старую работу.
Как вы планируете справляться со сбоями? Что, если Node.js выйдет из строя во время выполнения задания, повлияет ли это на ваших пользователей? Не могли бы вы затем повторить неудачное задание? Как вы поддерживаете откат? За сколько попыток он должен полностью остановиться?
На эти вопросы есть ответы в реализации Bull, RabbitMQ и почти во всех решениях, которые вы найдете для своей текущей задачи.
Из того, что я заметил (child_process ), это реализация более низкого уровня (низкоуровневая в Node.js), что означает, что многие функции, которые вам обычно требуются (переключение при отказе / откат), не включены. Вам придется это реализовать.
Вот где обычно становится больше проблем, чем того стоит, хотя, по общему признанию, управление, мониторинг и развертывание сервера Redis также могут быть не самым оптимальным решением.
Рассматривали ли вы другой подход, как будет работать работа periodi c CRON? (Например).
Проблема с такой системой обычно заключается в том, как вы планируете справляться с ошибками и какое влияние сбой оказывает на ваше приложение и конечных пользователей.
Я скажу, что в защита Bull, для задачи с интенсивным использованием ЦП я предпочитаю иметь отдельный экземпляр рабочего процесса, затем я могу повторно развернуть этот единственный процесс столько раз, сколько мне нужно. Благодаря этому мой внутренний код отделен и, как правило, легче управлять, а также дает мне возможность легко масштабироваться вверх / вниз при необходимости.
РЕДАКТИРОВАТЬ: Я упоминаю «больше проблем, чем оно того стоит», если вы действительно хотите узнать, как разрабатывается подобная технология, go с дочерним процессом и создайте свои собственные абстракции поверх, если это то, что вам нужно сегодня, используйте Bull, RabbitMQ или любую специальную альтернативу.