Proč je sdílení spojení (connection pooling) důležité při používání Redisu?

Question

Accepted Answer

**Sdílení spojení (connection pooling)** znovu využívá sadu zavedených Redis připojení across many requests namísto otevírání a zavírání připojení pro každou operaci. Je důležité pro výkon a efektivitu zdrojů v aplikacích, které zpracovávají souběžné požadavky, a většina Redis klientů sdílí spojení ve výchozím nastavení.

## Problém: overhead spojení

```text
Opening a new connection per request is wasteful:
  → TCP handshake + (TLS handshake) + AUTH on EVERY request → latency + CPU
  → many short-lived connections exhaust file descriptors / Redis's client limit
→ Under load, creating/destroying connections becomes a real bottleneck.
```

## Sdílení spojení: opětovné použití připojení

```js
// a pool maintains a set of ready connections, reused across requests
const redis = new Redis({
  host: "localhost",
  // client libraries manage a pool internally (or you configure pool size)
});
// each request borrows a connection from the pool and returns it — no per-request connect
```

Pool udržuje počet otevřených, ověřených připojení připravených; každá operace si jednu vypůjčí a vrátí — vyhnuto se tak per-request connect/auth overhead a omezení celkového počtu připojení.

## Důležité úvahy

```text
✓ POOL SIZE — enough connections for your concurrency, but not so many that you exhaust
  Redis's connection limit (many app instances × big pools = too many connections)
✓ Redis is single-threaded → a few connections can drive high throughput (don't over-size)
✓ BLOCKING commands (BLPOP, SUBSCRIBE) hold a connection → use SEPARATE connections/pools
  for blocking/pub-sub operations (so they don't starve the pool)
✓ Handle reconnection/failover gracefully (connections drop; clients should reconnect)
```

## Proč na tom záleží

Pochopení sdílení spojení je cenné pro **efektivní používání Redisu v reálných aplikacích**, praktickou operační záležitost, která ovlivňuje výkon a stabilitu pod zátěží.

Základní problém, který řeší — **overhead otevření spojení na požadavek** (TCP a případně TLS handshake plus ověření u každé operace, přidávající latenci a CPU, a riziko vyčerpání deskriptorů souborů nebo Redisova limitu připojení klientů s mnoha krátkodobými připojeními) — se stává skutečným úzkým místem při souběžnosti, takže opětovné použití spojení přes **pool** (udržování připravených, ověřených spojení, která si požadavky vypůjčují a vracejí) je důležité pro efektivitu a je standardním přístupem (většina klientů sdílí spojení ve výchozím nastavení).

Pochopení **úvah** odráží zralé používání: správné velikosti poolu (dost na souběžnost, ale ne tolik, aby násobením across aplikační instance vyčerpaly Redisův limit připojení — a protože je Redis single-threaded, skromný počet připojení může dosáhnout vysoké propustnosti, takže předimenzování je kontraproduktivní), a zásadně zpracování **blokujících a pub/sub příkazů** (které drží připojení po dobu jejich trvání) pomocí samostatných připojení nebo poolů, aby nestarvovaly hlavní pool — skutečná zrada v aplikacích, které míchají blokující operace s regulárními příkazy.

Znalost milého zpracování reconnection a failover doplňuje obrázek.

Protože aplikace pod zátěží intenzivně interagují s Redisem a správa spojení přímo ovlivňuje výkon a stabilitu, a protože sdílení (se správnou velikostí a zpracováním blokujících příkazů) je standardní, důležitou technikou pro efektivní používání spojení, pochopení sdílení spojení — overhead, který se vyhýbá, jak funguje, a úvahy k velikosti/blokování — je cenná, prakticky relevantní znalost pro správné a efektivní používání Redisu v produkčních aplikacích.