Jak funguje clustering v RabbitMQ?

Question

Accepted Answer

**Clustering** propojuje více RabbitMQ uzlů do jednoho logického brokera — pro škálovatelnost a (s replikovanými frontami) vysokou dostupnost. Pochopení clusteringu a jeho nuancí je důležité pro spolehlivé škálování a provoz RabbitMQ.

## Co je cluster

```text
A RabbitMQ CLUSTER = multiple nodes acting as ONE logical broker:
  → nodes share METADATA (queue/exchange definitions, bindings, users, vhosts) across the cluster
  → clients can connect to any node; load is distributed across nodes
  → scales connection/channel capacity and distributes load
```

## Fronty v clusteru (důležitá nuance)

```text
⚠️ By default, a queue's DATA lives on ONE node (the node where it was declared):
  → other nodes know about the queue (metadata) but route to the owning node
  → if that node FAILS → the queue (and its messages) is UNAVAILABLE
  → so CLUSTERING ALONE does NOT make queues highly available!
→ for HA → use REPLICATED queues (QUORUM QUEUES) that replicate data across nodes
```

## Úvahy k clusteringu

```text
✓ QUORUM QUEUES → replicate queue data across nodes (consensus-based) → survive node failure (HA)
✓ NETWORK PARTITIONS → split-brain risk → configure a partition-handling strategy
  (pause_minority, etc.) → cluster must agree on state
✓ Nodes should be on a reliable, low-latency network (clustering is sensitive to network issues)
✓ LOAD BALANCER → distribute client connections across nodes
✓ For geo-distribution → use FEDERATION/SHOVEL (not clustering across high-latency links)
```

## Proč na tom záleží

Pochopení, jak clustering funguje v RabbitMQ, je cenná znalost na seniorské úrovni, protože **clustering je důležitý pro škálování a vysokou dostupnost**, má však nuance, které musí být pochopeny pro spolehlivý provoz.

Clustering propojuje více uzlů do jednoho logického brokera, což je důležité pro produkční RabbitMQ.

Pochopení **co je cluster** — více uzlů fungujících jako jeden logický broker, sdílející metadata mezi uzly, přičemž se klienti mohou připojit k jakémukoliv uzlu a zátěž je distribuována — vyjasňuje základní koncept (škálování kapacity připojení a distribuce zátěže).

Zásadně je pochopení **důležité nuance o frontách v clusteru** — že ve výchozím nastavení data fronty žijí na jednom uzlu (ostatní uzly znají metadata, ale směrují do vlastnícího uzlu), takže pokud se tento uzel nezdaří, fronta a její zprávy jsou **nedostupné**, což znamená, že **clustering sám o sobě NEJEDNÁ vysokou dostupnost front** — nezbytné, protože se jedná o běžné, důsledné nedorozumění (lidé předpokládají, že clustering dává vysokou dostupnost, ale pro data front ne).

Pochopení, že **vysoká dostupnost vyžaduje replikované fronty (quorum queues)**, které replikují data mezi uzly, je klíčový poznatek.

Pochopení **úvah k clusteringu** — používání quorum queues pro vysokou dostupnost, řešení **rozdělení sítě** (riziko split-brain, vyžadující strategii pro řešení rozdělení), udržování uzlů na spolehlivé síti s nízkou latencí (clustering je citlivý na problémy se sítí), používání load balanceru pro připojení a používání **federace/shovel pro geografickou distribuci** (ne clustering přes vysokolatentní spojení — důležitý architektonický bod) — odráží správný provoz clusterů.

Tyto nuance (clustering ≠ vysoká dostupnost front, řešení rozdělení, citlivost sítě, geografická distribuce přes federaci) jsou důležité pro spolehlivý clustering.

Protože clustering je důležitý pro škálování a vysokou dostupnost, ale má zásadní nuance (zvláště že clustering sám o sobě neobstará vysokou dostupnost front — jsou potřeba replikované quorum queues, plus řešení rozdělení a citlivost sítě), a protože pochopení těchto aspektů je důležité pro spolehlivý provoz, je pochopení, jak clustering funguje v RabbitMQ, cenná seniorské úrovni znalost — důležitá pro škálování a vysokou dostupnost, s kritickou nuancí, že clustering sám o sobě neposkytuje vysokou dostupnost front (vyžaduje quorum queues), plus úvahy o řešení rozdělení a geografické distribuci, a odrážejí operační znalosti potřebné pro spolehlivý clustering RabbitMQ.