O que é pipelining no Redis e quando você deve usá-lo?

Question

Accepted Answer

**Pipelining** envia múltiplos comandos Redis em uma única viagem de ida e volta pela rede em vez de aguardar a resposta de cada comando antes de enviar o próximo. Melhora dramaticamente a taxa de transferência ao emitir muitos comandos, porque a latência de rede — e não o Redis em si — costuma ser o gargalo.

## O problema: latência de ida e volta

```text
Normally each command is a request→reply round-trip:
  send GET → wait for reply → send GET → wait for reply → ... (N × network latency)
→ Redis processes each command in microseconds, but each round-trip adds network
  latency (e.g. 0.5ms). For 1000 commands, that's ~500ms JUST in waiting!
```

## Pipelining: agrupe os comandos

```js
// send all commands at once, then read all replies — ONE round-trip
const pipeline = redis.pipeline();
for (const id of userIds) pipeline.get(`user:${id}`);
const results = await pipeline.exec();   // all replies returned together
// => 1000 commands in ~one round-trip instead of 1000 → dramatically faster
```

O cliente envia muitos comandos sem aguardar, depois lê todas as respostas juntas — colapsando N viagens de ida e volta em aproximadamente uma, uma aceleração enorme para operações em massa.

## Pipelining vs transações vs MGET

```text
PIPELINING → batches commands for THROUGHPUT (NOT atomic — other clients' commands
  can interleave between your pipelined commands; it's just network batching)
MULTI/EXEC → atomic execution (commands run together, no interleaving) — different goal
MGET/MSET  → batch GETs/SETs in one command (use these for simple multi-key string ops)
→ Pipelining is for throughput; transactions are for atomicity. They can combine.
```

## Quando usá-lo

```text
✓ Doing MANY independent commands (bulk reads/writes, batch processing, warming a cache)
✓ When network latency dominates (client and Redis have non-trivial latency between them)
✗ NOT needed for a single command, or when each command depends on the previous reply
⚠️ Don't pipeline a HUGE number at once (memory for buffered replies) — batch in chunks
```

## Por que isso importa

Entender pipelining é valioso para **otimizar a taxa de transferência do Redis**, uma preocupação prática comum quando uma aplicação emite muitos comandos Redis.

A percepção-chave é que o Redis é tão rápido que **a latência de ida e volta da rede, e não o processamento do Redis, é frequentemente o gargalo** ao fazer muitas operações — cada ida e volta de solicitação-resposta de comando adiciona latência de rede, então 1000 comandos sequenciais podem passar a maior parte do tempo apenas aguardando na rede. **Pipelining** resolve isso agrupando muitos comandos em aproximadamente uma viagem de ida e volta (enviando todos, depois lendo todas as respostas juntas), frequentemente transformando centenas de milissegundos em poucos — uma aceleração dramática e frequentemente impactante para operações em massa como leituras/escritas em lote, aquecimento de cache e processamento em massa.

Entender a **distinção das transações** é importante: pipelining é puramente agrupamento de rede para taxa de transferência e **não é atômico** (comandos de outros clientes podem se intercalar), enquanto `MULTI`/`EXEC` fornece atomicidade — objetivos diferentes que às vezes são confundidos, e usar o correto importa.

Saber **quando usá-lo** (muitos comandos independentes onde a latência domina) e quando não usá-lo (comandos únicos, ou quando cada comando depende da resposta anterior, ou agrupar muitos de uma vez e esgotar a memória para respostas armazenadas em buffer) reflete bom julgamento prático.

Como emitir muitos comandos Redis é comum e a latência de rede frequentemente domina, e como pipelining é a técnica padrão e altamente eficaz para agrupá-los de forma eficiente (distinto de mecanismos de transações), entender pipelining — o problema de latência que resolve, como funciona, sua diferença dos mecanismos de atomicidade e quando aplicá-lo — é conhecimento valioso e praticamente relevante do Redis para construir aplicações performáticas que interagem intensamente com Redis.