Voltar ao blog

Concorrência no Node.js: Explorando Worker Threads, Cluster e Event Loop

Concorrência no Node.js: Explorando Worker Threads, Cluster e Event Loop

Introdução: O Node.js é famoso por seu modelo single-thread baseado em Event Loop, que lida muito bem com operações de I/O não-bloqueantes. Em outras palavras, ele consegue atender milhares de conexões simultâneas sem travar, pois delega tarefas de I/O (como leitura de arquivos ou requisições de rede) para o sistema operacional, mantendo sua thread principal livre para outras tarefas (imasters.com.br). No entanto, esse modelo tem um ponto fraco: tarefas pesadas de CPU (como cálculos complexos, compressão de imagens, criptografia etc.) podem bloquear o event loop, degradando a performance e a experiência do usuário (www.rocketseat.com.br). Para resolver isso, o Node.js oferece mecanismos de concorrência adicionais: Worker Threads (múltiplas threads dentro de um processo) e Cluster (múltiplos processos). Neste artigo didático, vamos entender como o Event Loop funciona, quando usamos Worker Threads ou Cluster, e como otimizar nossas aplicações para alta performance.

O Event Loop no Node.js

Para compreender a concorrência em Node, primeiro precisamos entender o Event Loop. Em Node.js, todo código JavaScript padrão é executado numa única thread principal de eventos. O Event Loop é como uma fila de tarefas: quando uma operação assíncrona é solicitada, ela é delegada (por exemplo, para o sistema operacional), e assim que concluída, um callback (ou uma promessa) é enfileirado para ser executado quando a thread principal ficar livre. Enquanto não há nada pendente na fila, a thread principal continua executando o código JavaScript.

Por exemplo, veja este código:

console.log('Primeiro');
setTimeout(() => console.log('Timeout!'), 0);
console.log('Último');

Aqui, o setTimeout com 0ms agenda o callback para logo adiante no loop de eventos, mas não bloqueia o script. A saída será:

Primeiro
Último
Timeout!

Isso mostra que mesmo definindo setTimeout(..., 0), o texto "Último" é exibido antes. O Event Loop lidou com a tarefa assíncrona sem bloqueios, permitindo que o programa continuasse a executar.

Tarefas Bloqueantes vs Não-bloqueantes

A diferença entre tarefas bloqueantes (síncronas) e não-bloqueantes (assíncronas) é crucial. ‌Operações síncronas fazem com que o Event Loop espere até terminarem, travando a execução de outras tarefas. Por exemplo:

const fs = require('fs');
console.log('Leitura síncrona iniciada...');
const data = fs.readFileSync('arquivo-grande.txt'); // Lê arquivo de forma síncrona
console.log('Conteúdo do arquivo:', data.length);
console.log('Após leitura síncrona');

Neste caso, readFileSync bloqueia o Event Loop até terminar de ler o arquivo. Se o arquivo for grande, nada mais acontece (nem atender outras requisições!) até a leitura acabar. Uma boa prática é evitar funções síncronas no Node, sobretudo em servidores.

Em contraste, uma versão não-bloqueante seria:

const fs = require('fs');
console.log('Leitura assíncrona iniciada...');
fs.readFile('arquivo-grande.txt', (err, data) => {
  if (err) throw err;
  console.log('Conteúdo do arquivo:', data.length);
});
console.log('Após chamada assíncrona');
// O log "Após chamada assíncrona" aparece antes de "Conteúdo do arquivo"

Aqui, readFile delega a leitura ao sistema e retorna imediatamente, permitindo que o código siga. Assim que a leitura terminar, o callback é enfileirado e executado mais tarde. Essa é a beleza do Node: precisamos usar rotinas assíncronas para manter o Event Loop fluindo.

No entanto, operá­­­ções de CPU intensiva (contagem em loops, criptografia, etc.) não são delegáveis ao sistema e vão travar o Event Loop. Imagine um loop for enorme – enquanto esse loop roda, nenhuma outra parte do seu código pode ser executada. Para ilustrar:

console.log('Início da tarefa bloqueante');
const start = Date.now();
while (Date.now() - start < 2000) {
  // loop de 2 segundos, travando o event loop
}
console.log('Fim da tarefa bloqueante');
setTimeout(() => console.log('Tarefa assíncrona executada'), 0);

Saída provável:

Início da tarefa bloqueante
Fim da tarefa bloqueante
Tarefa assíncrona executada

Note que a mensagem "Tarefa assíncrona executada" só aparece depois dos 2 segundos do loop, comprovando que a tarefa síncrona bloqueou o loop. Nesses casos, precisamos de outras estratégias, como Worker Threads ou Cluster, que veremos a seguir.

Worker Threads: Paralelizando tarefas de CPU

Quando enfrentamos tarefas intensivas de CPU (cálculos matemáticos complexos, processamento de imagens, criptografia), o Node.js permite criar threads adicionais com o módulo worker_threads. Cada Worker Thread é uma verdadeiramente nova thread de execução dentro do mesmo processo Node, com própria pilha de chamadas. Dessa forma, podemos paralelizar trabalho pesado, sem travar a thread principal que mantém o servidor responsivo.

Pense em um cozinheiro principal numa cozinha tentando preparar um banquete sozinho (o Event Loop). Se um prato leva muito tempo, ele não consegue preparar outros pratos ao mesmo tempo. Os Worker Threads seriam como cozinheiros auxiliares que podem preparar pratos demorados em paralelo, permitindo que o cozinheiro principal continue cuidando de tarefas mais leves (I/O, requisições, etc.).

Para usar Worker Threads, fazemos algo assim:

// arquivo: main.js
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');

if (isMainThread) {
  // Código executado na thread principal
  console.log('Main thread PID:', process.pid);
  const worker = new Worker(__filename, { workerData: { quantidade: 1e7 } });
  
  worker.once('message', (result) => {
    console.log('Resultado do worker:', result);
  });
  worker.once('exit', (code) => {
    console.log(`Worker saiu com código ${code}`);
  });
} else {
  // Código executado dentro do Worker
  // O workerData contém dados passados pela main thread
  const { quantidade } = workerData;
  
  // Função pesada de exemplo: soma de números de 1 até N
  function somaPesada(n) {
    let total = 0;
    for (let i = 1; i <= n; i++) {
      total += i;
    }
    return total;
  }
  
  // Executa a tarefa pesada
  const resultado = somaPesada(quantidade);
  
  // Envia o resultado de volta para a thread principal
  parentPort.postMessage(resultado);
}

Neste exemplo, executamos node main.js. O código detecta se está na thread principal (isMainThread é true). Se for, criamos um novo Worker, passando o próprio arquivo (__filename) e alguns dados iniciais (workerData). O Worker inicia e executa o ramo else, fazendo a soma pesada. Quando termina, envia o resultado de volta com parentPort.postMessage, que é recebido pela main thread no evento 'message'. Enquanto isso, a main thread ficou livre para continuar outras operações.

Pontos importantes sobre Worker Threads:

  • Memória Compartilhada: Por padrão, cada Worker tem sua própria memória, mas é possível compartilhar buffers com SharedArrayBuffer se necessário. Isso exige cuidado com sincronização.
  • Overhead: Criar um Worker tem um custo (overhead). Se você precisa executar tarefas CPU-bound repetidamente, o ideal é criar um pool de Workers, reutilizando-os, em vez de criar e encerrar a todo momento (nodejs.org).
  • Comunicação: A comunicação ocorre via mensagens (postMessage/message), que copiam dados ou transferem TypedArrays. Não podemos simplesmente acessar variáveis do código principal.

Com Worker Threads, podemos delegar cálculos pesados e manter a thread principal livre para I/O. Por exemplo, num servidor HTTP, você pode em cada requisição de processamento intensivo dar o trabalho para um Worker e responder a outros pedidos simultaneamente.

Exemplo prático de Worker Threads

Vamos a um exemplo realista. Suponha que queremos calcular números da sequência de Fibonacci de forma recursiva (CPU-bound) e não travar o servidor:

fib-worker.js (código do worker):

const { parentPort, workerData } = require('worker_threads');

// Função recursiva de Fibonacci (ineficiente, só para fins didáticos)
function fib(n) {
  if (n < 2) return 1;
  return fib(n - 1) + fib(n - 2);
}

const resultado = fib(workerData.n);
parentPort.postMessage(resultado);

main.js (código principal):

const { Worker } = require('worker_threads');

function calcularFibonacci(n) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./fib-worker.js', { workerData: { n } });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0)
        reject(new Error(`Worker saiu com código ${code}`));
    });
  });
}

async function main() {
  console.log('Calculando fib(40) em um Worker Thread...');
  const resultado = await calcularFibonacci(40);
  console.log('Resultado da fib(40):', resultado);
}

main();

Ao executar node main.js, o cálculo da fib(40) é feito no Worker Thread, e a main thread permanece disponível para outras tarefas. Observe que usamos Promise para lidar com o resultado de forma assíncrona.

Cluster: escalando com múltiplos processos

Além dos Worker Threads, o Node.js oferece o módulo cluster, que permite criar vários processos do Node (cada um com seu próprio Event Loop) trabalhando em conjunto. Cada cópia de processo é chamada de worker do cluster. Essa técnica aproveita múltiplos núcleos de CPU e faz o balanceamento de carga para distribuir requisições entre eles.

Pense no cluster como ter várias cozinhas independentes (processos), cada uma atendendo pedidos dos clientes. Embora cada cozinha use recursos duplicados (memória separada), elas permitem servir múltiplos pedidos simultaneamente, melhorando a escalabilidade horizontal.

Um exemplo básico de servidor HTTP com cluster:

// cluster-server.js
const cluster = require('cluster');
const http = require('http');
const os = require('os');

const numCPUs = os.cpus().length; // Quantidade de núcleos da CPU

if (cluster.isMaster) {
  console.log(`Processo master (${process.pid}) está rodando`);

  // Cria um worker para cada CPU
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  // Se algum worker morrer, cria um novo
  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} morreu. Código: ${code || signal}`);
    console.log('Criando um novo worker...');
    cluster.fork();
  });
} else {
  // Esse bloco é executado nos processos workers
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Olá do worker ${process.pid}`);
  }).listen(8000, () => {
    console.log(`Worker ${process.pid} iniciado, escutando na porta 8000`);
  });
}

Ao executar este arquivo (node cluster-server.js), o processo master instancia um worker para cada núcleo da máquina. Cada worker cria um servidor HTTP que escuta a mesma porta (8000). O Node.js faz o balanceamento interno das requisições recebidas entre os workers. Assim, se você tiver 4 núcleos, receberá 4 processos Node compartilhando o tráfego. Se um worker travar, o master detecta pelo evento 'exit' e recria outro, garantindo alta tolerância a falhas.

Pontos-chave do Cluster:

  • Processos Independentes: Cada worker é um processo Node separado, com memória própria. Isso garante isolamento (se um trava, os outros continuam).
  • Compartilhamento de Porta: Por padrão, o cluster distribui conexões TCP automaticamente. Não precisamos de código extra para isso.
  • Uso Ideal: Clusters são ótimos para aplicativos principalmente I/O-bound, como servidores HTTP, pois podem escalar linearmente com mais CPUs.
  • Overhead: Como cada processo é completo, há mais consumo de memória. Veja o trade-off: melhor escalabilidade vs maior recurso usado.

A tabela abaixo resume bem as diferenças:

CaracterísticaClusterWorker Threads
Uso idealI/O intensivo (ex.: HTTP)CPU intensivo (ex.: cálculo)
EstruturaMúltiplos processosMúltiplas threads
MemóriaMemória separada por processoMemória compartilhada possível
Tolerância a falhasAlta (isolamento de processos)Moderada (um processo geral)

Fonte: artigo da Rocketseat sobre Node.js e escalabilidade (www.rocketseat.com.br).

Boas práticas e otimização do Event Loop

Agora que conhecemos Event Loop, Worker Threads e Cluster, como combiná-los e otimizar nossa aplicação? Aqui vão algumas dicas:

  • Use hardware disponível: Se sua aplicação faz muito processamento, utilize Cluster para escalar horizontalmente em várias CPUs. Para tarefas isoladas de CPU dentro de um mesmo processo, use Worker Threads. Em alguns casos, você pode combinar ambos: o processo master delega requisições com Cluster e cada servidor ainda pode usar Workers para cálculos pesados (www.rocketseat.com.br).

  • Evite bloqueio no Event Loop: Fuja de funções síncronas (fs.readFileSync, loops pesados, criptografia síncrona etc.). Prefira sempre APIs assíncronas (promises, callbacks) para I/O. Para processamentos que não dão para tornar assíncronos, delegue a um Worker ou a um processo filho.

  • Divida tarefas grandes: Se tiver operações grandes, considere fracioná-las. Por exemplo, em vez de calcular próximo bloco de 1 milhão de iterações de uma vez, faça em partes usando setImmediate ou setTimeout(…, 0) entre lotes. Isso libera o Event Loop para outras tarefas e evita que uma única operação ocupe demasiado tempo.

  • Monitore o Event Loop: Ferramentas como o módulo perf_hooks (monitorEventLoopDelay) ou pacotes como clinic.js ajudam a identificar gargalos no loop de eventos. Se você notar lentidão (lag) nas respostas, investigue se há funções travando o loop.

  • Compartilhe dados com cuidado: Se usar Worker Threads e precisar compartilhar grandes buffers entre threads, use transferíveis ou SharedArrayBuffer para evitar cópias excessivas. Isso mantém o desempenho.

  • Considere alternativas de arquitetura: Em aplicações muito críticas, você pode até separar micro-serviços de tarefas CPU-bound em outra stack (outra instância Node, ou serviço em outra linguagem). Porém, na maioria dos casos, cluster e worker threads no próprio Node bastam para atender a demanda.

Por fim, lembre-se: modo de concorrência não é uma solução mágica. Ele exige planejamento. Cada ambiente é único, então teste: por exemplo, meça quantas requisições seu servidor aguenta com e sem Cluster, ou com X Workers vs Y Workers para encontrar a configuração ideal.

Conclusão

Concorrer e paralelizar em Node.js significa explorar bem event loop, Worker Threads e Cluster. O modelo assíncrono de Node faz muito bem o básico: lidar com múltiplas requisições e I/O simultâneo sem travar. Mas, para tarefas CPU-intensivas, precisamos dos mecanismos extras. Os Worker Threads liberam o event loop ao aplicar multitasking dentro do mesmo processo, e o Cluster permite usar todos os núcleos do servidor distribuindo carga entre processos.

Em resumo:

  • O Event Loop do Node é single-threaded, ótimo para I/O não-bloqueante, mas sensível a código síncrono pesado (www.rocketseat.com.br).
  • Worker Threads são ideais para paralelização de cálculos ou tarefas que consomem CPU, executando em múltiplas threads dentro do processo.
  • Cluster é a estratégia padrão para escalar servidores em vários núcleos, criando processos independentes que recebem requisições em paralelo.
  • Otimizar significa evitar bloqueios, usar padrões assíncronos e combinar threads/processos conforme a necessidade da aplicação.

Dominar essas técnicas prepara você para reduzir gargalos e construir aplicações Node.js robustas e de alta performance. Na prática, experimente: implemente um pequeno WebService com Cluster, teste adicionar uma tarefa cara e "movê-la" para um Worker, veja o ganho de resposta do servidor. A ideia é que, ao fim, sua aplicação sirva mais usuários simultaneamente e de forma fluída, usando eficientemente toda a capacidade do servidor.

Quer aprender mais sobre Programação?

Você acabou de ganhar 1 hora com a minha equipe para uma call exclusiva! Vamos entender o seu momento e te mostrar o caminho para se tornar um programador de sucesso. Clique no botão abaixo e agende agora mesmo!

Agendar minha call gratuita