2017-02-05 3 views
1

Я пытался включить кластеризацию в моем приложении js для узла. В настоящее время я использую этот фрагмент кода, чтобы включить его:узел js кластеризация повторяет одну и ту же задачу для всех 8 процессов

var cluster = require('cluster'); 

if (cluster.isMaster) { 
    // Count the machine's CPUs 
    var cpuCount = require('os').cpus().length; 

    // Create a worker for each CPU 
    for (var i = 0; i < cpuCount; i += 1) { 
    cluster.fork(); 
    } 

    // Listen for dying workers 
    cluster.on('exit', function() { 
    cluster.fork(); 
    }); 
} 

И в основном мой код выполняет запись в виде Firebase базы данных на основе условий. Проблема в том, что записи происходят по 8 раз каждый, а не один рабочий, просто заботящийся о одной задаче записи, кажется, что все потоки выполняют все задачи. Есть ли способ избежать этого? Если да, может кто-нибудь указать мне в сторону некоторых ресурсов на это? Я не могу найти что-либо в google для использования Firebase с кластером узлов js. Вот пример того, как один из моих функций работы (см моего firebase ссылки):

ref.child('user-sent').on('child_added', function(snapshot) { 

      var message = snapshot.child('message'); 

      payload['user-received/'] = message; 

      ref.update(payload); // this occurs once for each fork so it updates 8 times 
    }); 

ответ

1

Если вы нерест 8 потоков и каждый поток присоединяет слушатель на то же место (user-sent), то каждый thread будет запускать событие child_added для каждого дочернего объекта в этом месте. Это ожидаемое поведение.

Если вы хотите реализовать рабочую очередь, где каждый узел под user-sent обрабатывается только одним потоком, вам придется использовать механизм распределения работы, который гарантирует, что только один поток может претендовать на каждый узел.

firebase-queue library реализует такой механизм подачи заявки, используя транзакции базы данных Firebase. Он используется для масштабирования для небольшого и среднего числа рабочих (думаю, < 10, а не десятки).

+0

Спасибо, Фрэнк! Я задаюсь вопросом, почему вы посоветовали бы не масштабировать более 10 работников? Это связано с тем, что транзакции не масштабируются хорошо? Мне может понадобиться масштабировать 10+, но для меня основным узким местом является интенсивный расчет процессора и фактически не обновляющий мою Firebase, поэтому я могу как-то разгрузить эту часть где-то еще. – Aretyper

+0

В какой-то момент вы столкнетесь с проблемами конкуренции, так как все рабочие изменяют одну и ту же очередь задач. Все зависит от размера операций, конечно, так ymmv. Если вы столкнетесь с такими ограничениями, рассмотрите альтернативные системы распределения работы. Что-то менее демократичное (например, одна служба распределения работы), скорее всего, будет расширяться, поскольку, вероятно, будет меньше споров. –

+0

Вижу, спасибо за объяснение. Последнее, если вы не возражаете, я написал простую реализацию очереди для подталкивания полезных данных к Firebase и запустил 6 процессов с 100 элементами в очереди, чтобы проверить, насколько хорошо рабочие распределяют работу, и я получаю 3 рабочих почти вся работа с другими тремя, только принимая по 2 задания каждый из 100, как показано здесь http://i.imgur.com/V1WwCI9.png, вы знаете, возможно, почему это происходит? Будет ли это зависеть от моего кода или это функция того, как выполняется очередь? Еще раз спасибо. – Aretyper

 Смежные вопросы

  • Нет связанных вопросов^_^