Node.js Backend Development Bootcamp · 강의

작업 큐, 프리페치 및 경쟁 소비자

프리페치 제한과 경쟁 소비자 패턴으로 소비자 간 부하를 공정하게 분산합니다.

작업 큐, 프리페치 및 경쟁 소비자은(는) CoddyKit의 무료 Node.js Backend Development Bootcamp 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Node.js Backend Development Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Work Queues?

A work queue (sometimes called a task queue) lets your Node.js backend push time-consuming jobs to a queue instead of running them inside the HTTP request. Think image resizing, sending emails, or generating PDFs.

The producer publishes a small message describing the job.
One or more consumers (worker processes) pull jobs and execute them in the background.
The HTTP response returns immediately, keeping your API fast.

RabbitMQ stores the messages durably until a worker is free to process them.

A Minimal Producer

The producer connects to RabbitMQ, declares a durable queue, and sends a task message. Each message is just a buffer of bytes — here we send a plain string describing the job.

Notice { durable: true } on the queue and { persistent: true } on the message. Together they let tasks survive a broker restart.

const amqp = require('amqplib');

async function send(task) {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  const queue = 'tasks';

  await ch.assertQueue(queue, { durable: true });
  ch.sendToQueue(queue, Buffer.from(task), { persistent: true });
  console.log('Sent: %s', task);

  await ch.close();
  await conn.close();
}

send('resize-image:42');

A Minimal Consumer

The consumer asserts the same durable queue and registers a callback with ch.consume. Whenever a message arrives, RabbitMQ delivers it to the handler.

Here we simulate work by counting the dots in the message body, then sleeping that many seconds. The queue name is the contract that links producer and consumer.

const amqp = require('amqplib');

async function worker() {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  const queue = 'tasks';

  await ch.assertQueue(queue, { durable: true });
  console.log('Waiting for tasks...');

  ch.consume(queue, (msg) => {
    const body = msg.content.toString();
    console.log('Received: %s', body);
  });
}

worker();

Acknowledgements Prevent Lost Work

By default, manual acknowledgements protect you from losing jobs if a worker crashes. With { noAck: false }, RabbitMQ keeps a message in an unacknowledged state until the worker calls ch.ack(msg).

If the worker dies before acking, RabbitMQ requeues the message and another worker picks it up.
Always ack after the work succeeds, never before.
Use ch.nack(msg, false, requeue) to reject a poisoned message.

ch.consume(queue, async (msg) => {
  try {
    await doWork(msg.content.toString());
    ch.ack(msg);            // success: remove from queue
  } catch (err) {
    ch.nack(msg, false, false); // failure: drop (or send to DLX)
  }
}, { noAck: false });

Competing Consumers Pattern

The competing consumers pattern simply means: run multiple worker processes that all consume from the same queue. RabbitMQ delivers each message to exactly one of them.

Want more throughput? Start more workers — no code change needed.
The queue acts as a load buffer during traffic spikes.
This is how you scale background processing horizontally in Node.js.

But how RabbitMQ chooses which worker gets the next message matters a lot.

The Problem: Round-Robin Dispatch

Out of the box, RabbitMQ dispatches messages to consumers in a strict round-robin order — it counts messages, not workload.

Imagine two workers. The queue has tasks where odd-numbered ones are heavy and even-numbered ones are light. Round-robin sends every other task to each worker, so one worker may end up with all the heavy jobs while the other sits idle.

RabbitMQ does not look at how busy a consumer already is — unless you tell it to with prefetch.

Prefetch: Limit Unacked Messages

Prefetch (QoS) caps how many unacknowledged messages a single consumer may hold at once. You set it per channel with ch.prefetch(count).

ch.prefetch(1) means: don't give a worker a new task until it has acked the previous one.
This turns dispatch from "round-robin by count" into "give the next task to whoever is free" — fair dispatch.
Higher values (e.g. 10) increase throughput by pipelining, at the cost of fairness.

const amqp = require('amqplib');

async function worker() {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  const queue = 'tasks';

  await ch.assertQueue(queue, { durable: true });
  await ch.prefetch(1); // fair dispatch: one in-flight task per worker

  ch.consume(queue, async (msg) => {
    await doWork(msg.content.toString());
    ch.ack(msg);
  }, { noAck: false });
}

worker();

Tuning the Prefetch Value

The right prefetch depends on your workload:

prefetch(1) — best for long, uneven, CPU-heavy tasks. Maximum fairness, slight latency between ack and next delivery.
prefetch(10–50) — best for short, uniform tasks (e.g. tiny webhook fan-out) where round-trip latency would otherwise dominate.

Rule of thumb: short tasks + low latency network → larger prefetch. Long tasks or unpredictable durations → small prefetch. Measure, then tune.

Simulating Fair Dispatch Locally

You don't need RabbitMQ to understand fair dispatch. This standalone program models a single shared queue and two workers under a prefetch=1 policy: each worker only takes a new job when it is free.

Heavy jobs take longer, so the free worker keeps grabbing the next task — the load self-balances instead of being split blindly by count.

const tasks = [5, 1, 5, 1, 5, 1]; // seconds of "work"
let clock = 0;
const workers = [
  { name: 'W1', freeAt: 0 },
  { name: 'W2', freeAt: 0 },
];

for (const cost of tasks) {
  // prefetch=1: assign to whichever worker is free soonest
  const w = workers.reduce((a, b) => (a.freeAt <= b.freeAt ? a : b));
  const start = Math.max(clock, w.freeAt);
  w.freeAt = start + cost;
  console.log(`${w.name} runs ${cost}s at t=${start}`);
}

const finish = Math.max(...workers.map((w) => w.freeAt));
console.log('All done at t=' + finish);

Prefetch Is Per-Channel, Per-Consumer

A common gotcha: ch.prefetch(count) applies to each consumer on that channel by default. If you run one worker process per queue, this is exactly what you want.

The limit counts only unacked messages, so forgetting to ack will stall the worker once it hits the cap.
A second optional argument, ch.prefetch(count, true), makes the limit apply across the whole channel (global), which is rarely needed.
One channel per worker process is the simplest, safest setup.

Putting It Together

A production-ready consumer combines all the pieces: a durable queue, fair-dispatch prefetch, manual acks on success, and nack on failure.

Run several copies of this exact file as separate processes and you have competing consumers that share load fairly. Scale up by launching more workers; scale down by stopping some — the queue absorbs the difference.

const amqp = require('amqplib');

async function start() {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  const queue = 'tasks';

  await ch.assertQueue(queue, { durable: true });
  await ch.prefetch(1);

  ch.consume(queue, async (msg) => {
    try {
      await handle(JSON.parse(msg.content.toString()));
      ch.ack(msg);
    } catch (err) {
      ch.nack(msg, false, false); // drop / route to dead-letter exchange
    }
  }, { noAck: false });
}

start().catch(console.error);

Quick Check

You run 3 worker processes consuming the same queue. Task durations vary wildly — some take 200ms, some take 30s. You notice one worker is always busy while others go idle, so jobs pile up. What is the most direct fix?

Recap

You learned how to distribute background work fairly across Node.js workers with RabbitMQ:

Work queues offload slow jobs from the request path into a durable queue.
Competing consumers means multiple workers consume the same queue; each message goes to exactly one worker, and you scale by adding processes.
Default dispatch is round-robin by count, which can overload one worker with heavy tasks.
Prefetch (ch.prefetch(n)) caps unacked messages per consumer; prefetch(1) gives fair dispatch, higher values pipeline short tasks.
Always use manual acks (ch.ack on success, ch.nack on failure) so crashed workers don't lose jobs.

자주 묻는 질문

“작업 큐, 프리페치 및 경쟁 소비자” 강의는 무료인가요?

네 — “작업 큐, 프리페치 및 경쟁 소비자” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Node.js Backend Development Bootcamp 강의 전체를 잠금 해제할 수 있습니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

“작업 큐, 프리페치 및 경쟁 소비자”에서 뭘 배우나요?

프리페치 제한과 경쟁 소비자 패턴으로 소비자 간 부하를 공정하게 분산합니다. 브라우저에서 직접 실행하는 실습 코드로 Node.js Backend Development Bootcamp을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Node.js Backend Development Bootcamp을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Node.js Backend Development Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“작업 큐, 프리페치 및 경쟁 소비자” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Node.js Backend Development Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Node.js Backend Development Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Node.js Backend Development Bootcamp(으)로 돌아가기