Što je pipelining u Redisu i kada ga trebate koristiti?

Question

Accepted Answer

**Pipelining** šalje više Redis naredbi u jednoj mrežnoj komunikaciji umjesto čekanja odgovora na svaku naredbu prije slanja sljedeće. Dramatično poboljšava propusnost pri slanju više naredbi, jer je mrežna latencija — ne sam Redis — često usko grlo.

## Problem: latencija komunikacije

```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: grupiraj naredbe

```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
```

Klijent šalje više naredbi bez čekanja, zatim čita sve odgovore zajedno — sažimajući N komunikacija u približno jednu, što je ogromno ubrzanje za masovne operacije.

## Pipelining protiv transakcija protiv 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.
```

## Kada ga koristiti

```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
```

## Zašto je važno

Razumijevanje pipelininga je vrijedno za **optimizaciju propusnosti Redisa**, što je čest praktičan problem kada aplikacija šalje mnogo Redis naredbi.

Klju čna spoznaja je da je Redis toliko brz da je **mrežna latencija komunikacije, ne samo obrada u Redisu, često usko grlo** pri izvođenju više operacija — svaka naredba zahtijeva komunikaciju za zahtjev-odgovor koja dodaje mrežnu latenciju, pa 1000 sekvencijalnih naredbi može provesti većinu vremena samo čekajući na mreži. **Pipelining** rješava ovo grupiranjem više naredbi u približno jednu komunikaciju (slanjem svih odjednom, zatim čitanjem svih odgovora zajedno), često pretvarajući stotine milisekundi u nekoliko — dramatično, često značajno ubrzanje za masovne operacije kao što su skupno čitanje/pisanje, zagrijavanje memorije i masovna obrada.

Razumijevanje **razlike od transakcija** je važno: pipelining je čisto mrežno grupiranje za propusnost i **nije atomski** (naredbe ostalih klijenata mogu se preplesti), dok `MULTI`/`EXEC` pruža atomičnost — različiti ciljevi koji se ponekad miješaju, i korištenje ispravnog je važno.

Znanje **kada ga koristiti** (mnogo nezavisnih naredbi gdje latencija dominira) i kada ga ne koristiti (jedan naredba, ili kada svaka naredba ovisi o prethodnom odgovoru, ili grupiranje previše odjednom i iscrpljivanje memorije za baferane odgovore) odražava dobar praktičan sud.

Budući da je slanje više Redis naredbi često i mrežna latencija često dominira, te budući da je pipelining standardna, vrlo učinkovita tehnike za njihovo efikasno grupiranje (drugačija od transakcija), razumijevanje pipelininga — problem latencije koji rješava, kako funkcionira, razlika od mehanizama atomičnosti i kada ga primijeniti — je vrijedna, praktično relevantna Redis znanja za izgradnju performantnih aplikacija koje intenzivno komuniciraju s Redisom.