Bull Concue Concurrency Вопросы - PullRequest
Новая
       26

Bull Concue Concurrency Вопросы

0 голосов
/ 10 января 2019

Мне нужна помощь, чтобы понять, как Bull Queue (bull.js) обрабатывает параллельные задания.

Предположим, у меня есть 10 экземпляров Node.js, каждый из которых создает очередь Bull, подключенную к одному экземпляру Redis: 

const bullQueue = require('bull');
const queue = new bullQueue('taskqueue', {...})
const concurrency = 5;
queue.process('jobTypeA', concurrency, job => {...do something...});

Означает ли это, что в глобальном масштабе во всех 10 экземплярах узлов будет максимально 5 (одновременных) одновременно запущенных заданий типа jobTypeA? Или я неправильно понимаю, и параметр параллелизма является экземпляром для узла?

Что произойдет, если один экземпляр Node определит другое значение параллелизма?

Могу ли я быть уверен, что задания не будут обрабатываться более чем одним экземпляром узла?

Ответы [ 3 ]

0 голосов
/ 13 января 2019

Рассматривая это подробнее, я думаю, что Bull вообще не обрабатывает распределение по нескольким экземплярам Node, поэтому поведение в лучшем случае не определено.

0 голосов
/ 12 мая 2019

TL; DR: при нормальных условиях задания обрабатываются только один раз. Если что-то пойдет не так (скажем, сбой процесса Node.js), задания могут быть обработаны дважды.

Цитата из официального заявления Булла README.md :

Важные замечания

Очередь нацелена на "хотя бы один раз" рабочую стратегию. Это означает, что в некоторых ситуациях задание может быть обработано более одного раза. В основном это происходит, когда работнику не удается сохранить блокировку для данного задания в течение общей продолжительности обработки.

Когда работник обрабатывает задание, он будет держать задание "заблокированным", чтобы другие работники не могли его обработать.

Важно понимать, как работает блокировка, чтобы предотвратить потерю блокировок вашими работами - становясь остановленным - и в результате перезапускаться. Блокировка реализуется внутренне путем создания блокировки для lockDuration на интервале lockRenewTime (который обычно равен половине lockDuration). Если lockDuration истекает до возобновления блокировки, задание будет считаться остановленным и будет автоматически перезапущено; это будет обработано дважды . Это может произойти, когда:

  1. Процесс Node, на котором выполняется ваш процессор заданий, неожиданно завершается.
  2. Ваш процессор заданий был слишком загружен процессором и остановил цикл событий Node, и в результате Bull не смог обновить блокировку задания (см. # 488, как мы могли бы лучше определить это). Это можно исправить, разбив ваш процессор заданий на более мелкие части, чтобы ни одна из частей не могла блокировать цикл событий Node. В качестве альтернативы, вы можете передать большее значение для параметра lockDuration (при этом компромисс заключается в том, что для распознавания реальной приостановленной работы потребуется больше времени).

Таким образом, вы всегда должны прослушивать событие stalled и регистрировать его в своей системе мониторинга ошибок, поскольку это означает, что ваши задания, вероятно, обрабатываются дважды.

Так как проблемные задания не будут перезапущены на неопределенный срок (например, если процессор заданий завершит работу после сбоя процесса Node), задания будут восстановлены из остановленного состояния максимум maxStalledCount раз (по умолчанию: 1) .

0 голосов
/ 10 января 2019

А, добро пожаловать! Это мета-ответ и, вероятно, не то, на что вы надеялись, а общий процесс решения этой проблемы:

Вы можете указать аргумент параллелизма. Бык тогда позвонит вашему параллельный обработчик с учетом этого максимального значения.

Лично я не очень понимаю это или гарантии, которые предоставляет бык. Поскольку это не супер ясно:

  • Погрузитесь в источник, чтобы лучше понять, что на самом деле происходит. Я обычно просто прослеживаю путь, чтобы понять:

  • Если предлагаемая реализация и гарантии все еще не ясны, то создайте контрольные примеры, чтобы попытаться опровергнуть предположения, это звучит так:

    • Инициализировать процесс для одной и той же очереди с двумя разными значениями параллелизма
    • Создайте очередь и двух рабочих, установите параллельный уровень 1 и обратный вызов, который регистрирует процесс обработки сообщений, затем время ожидания для каждого рабочего, ставит в очередь 2 события и наблюдает, обрабатываются ли оба одновременно или ограничено 1

ИМО самая большая вещь:

Могу ли я быть уверен, что задания не будут обрабатываться более чем одним узлом Экземпляр

Если эксклюзивная обработка сообщений является инвариантом и приведет к некорректности вашего приложения, даже при наличии отличной документации, я настоятельно рекомендую провести комплексную проверку библиотеки: p

...