Co je pipelining v Redisu a kdy jej měl bys použít?

Question

Accepted Answer

**Pipelining** odesílá více Redis příkazů v jednom síťovém round-tripu místo toho, aby klient čekal na odpověď každého příkazu před odesláním dalšího. Dramaticky zvyšuje propustnost při vydávání mnoha příkazů, protože síťová latence — ne samotný Redis — je často úzkým místem.

## Problem: latence round-tripu

```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: dávkování příkazů

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

Klient odešle mnoho příkazů bez čekání, poté přečte všechny odpovědi dohromady — sbalí N round-tripů do přibližně jednoho, obrovské zrychlení pro hromadné operace.

## Pipelining vs transakce 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.
```

## Kdy jej použít

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

## Proč je to důležité

Pochopení pipelingu je cenné pro **optimalizaci propustnosti Redisu**, běžné praktické obavy, když aplikace vydává mnoho Redis příkazů.

Klíčová myšlenka je, že Redis je tak rychlý, že **síťová latence round-tripu, ne zpracování Redisu, je často úzkým místem** při provádění mnoha operací — round-trip request-reply každého příkazu přidává síťovou latenci, takže 1000 sekvenčních příkazů může strávit většinu času pouze čekáním na síť. **Pipelining** to řeší dávkováním mnoha příkazů do přibližně jednoho round-tripu (odesílá je všechny, poté přečte všechny odpovědi dohromady), často превracet stovky milisekund na několik málo — dramatické, často impaktní zrychlení pro hromadné operace jako hromadné čtení/zápisy, zahřívání cache a hromadné zpracování.

Pochopení **rozlišení od transakcí** je důležité: pipelining je čistě síťové dávkování pro propustnost a **není atomický** (příkazy ostatních klientů se mohou prokládat), zatímco `MULTI`/`EXEC` poskytuje atomičnost — různé cíle, které jsou někdy zaměňovány, a používání toho správného záleží.

Vědět **kdy jej použít** (mnoho nezávislých příkazů, kde latence dominuje) a kdy ne (jednotlivé příkazy, nebo když každý příkaz závisí na předchozí odpovědi, nebo dávkování příliš mnoha najednou a vyčerpání paměti pro vyrovnávací paměť), odráží zdravý praktický úsudek.

Jelikož vydávání mnoha Redis příkazů je běžné a síťová latence často dominuje, a jelikož pipelining je standardní, vysoce efektivní technika pro jejich efektivní dávkování (odlišná od transakcí), pochopení pipelingu — problém latence, který řeší, jak funguje, jeho rozdíl od mechanismů atomicity a kdy jej aplikovat — je cenné, prakticky relevantní znalost Redisu pro budování výkonných aplikací, které intenzivně komunikují s Redisem.