После более глубокого изучения этой проблемы и успешного внедрения рабочих для решения исходной проблемы приведем сводку для всех, кто сталкивался с таким же сценарием.
Рабочие потоки узла и рабочие Heroku похожи в том, что они намеревались запускать код в отдельных потоках в узле, которые не блокируют основной поток. То, как вы их используете и реализуете, отличается и зависит от варианта использования.
Рабочие потоки узла
Это новый способ создания кластеризованных сред на NODE. Вы можете следовать документам NODE для создания рабочих или использовать что-то вроде микроджоба, чтобы упростить настройку и запуск отдельных потоков NODE для конкретных c задач.
https://github.com/wilk/microjob
Это прекрасно работает и будет намного эффективнее, поскольку они будут работать в отдельных рабочих потоках, предотвращая блокировку ввода-вывода.
Использование рабочих потоков в Heroku в веб-процессе не решило мою проблему, так как Интернет время ожидания запроса по истечении 30 секунд.
Важное отличие: рабочие Heroku не делают!
Workers Heroku
Это отдельные виртуальные контейнеры Dyno в Heroku в пределах одно приложение. Это отдельные процессы, которые выполняются без всех накладных расходов, выполняемых веб-процессом, например http.
Рабочие не слушают HTTP-запросы. Если вы используете Express с NODE, вам нужен веб-процесс для обработки входящих HTTP-запросов, а затем рабочий для обработки заданий.
Задача состояла в том, чтобы выяснить, как взаимодействовать между сетью и рабочими процессами. Это делается с помощью Redis и Bull Query для хранения данных и отправки сообщений между процессами.
Наконец, Throng упрощает создание кластерной среды с использованием Procfile, поэтому он идеально подходит для использования с Heroku!
Вот прекрасный пример, который реализует все вышеперечисленное в стартовом проекте, который Heroku сделал доступным.
https://devcenter.heroku.com/articles/node-redis-workers