Каков наилучший подход к автономному поддержанию состояния доступных работников? - PullRequest
0 голосов
/ 03 октября 2018

В настоящее время, как устроена моя система, я создаю 1-ядерный экземпляр, которому разрешено только одно задание на кодирование.Этот экземпляр подключается к Redis и ожидает заполнения списка заданий на кодирование.Затем работник извлекает задание из списка и становится занятым во время выполнения задания, как только задание выполнено, он продолжает искать незавершенные задания.

Мой пример worker.js

module.exports = function (redisClient) {
  const spawn = require('child_process').spawn;
  var busy = false;
  function startCoStream(job) {
    console.log(job);
    busy = true;
    var proc = spawn('./costream.sh', [job.streamKey, job.leftIngest, job.leftKey, job.rightIngest, job.rightKey]);
    proc.on('exit', function (code, signal) {
      busy = false;
      readJobBus();
    });
    proc.stderr.setEncoding('utf8');
    proc.stderr.on('data', (chunk) => { 
      console.log(chunk);
    });
  }
  function readJobBus () {
    if (busy) return;
    redisClient.lpop('jobbus', function(err, reply) {
      if (!reply && !err) {
        setTimeout(readJobBus, 1000);
      }
      else {
        var job = JSON.parse(reply);
        if (job.type==0) {
          startCoStream(job);
        }
      }
    });
  }
  readJobBus();
  return redisClient;
}

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

Идея 1) Зарегистрировать работника в доступном списке работников при запуске, затем удалить из списка при запуске процесса и добавить обратно после завершения процесса.Проблема 1) Что, если работник умрет, оставаясь в списке доступных, тогда в списке будет отображаться на 1 работника больше, чем реальное состояние приложения.

Что будет хорошим подходом к этому?Желаемый результат прост.Когда работник подготовлен, он подключается к Redis и помещает себя в список работников, когда в списке работников занято более половины работников, а затем выделяется больше работников.Что было бы лучшим способом сохранить этот список без специальной системы, поддерживающей этот список.

1 Ответ

0 голосов
/ 04 октября 2018

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

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

  1. Попытка получить блокировку супервизора, если она заблокирована, перейдите к # 4
  2. , проверьте количество занятых работников и при необходимости предоставьте больше
  3. выпуск блокировки супервизора
  4. поиск работы
...