Jak funguje vysoká dostupnost v RabbitMQ?

Question

Accepted Answer

**Vysoká dostupnost** v RabbitMQ zahrnuje **clustering** (více uzlů) a **replikované fronty** (zrcadlené nebo quorum fronty), takže systém přežije selhání uzlů bez ztráty zpráv. Pochopení HA je důležité pro spolehlivý produkční RabbitMQ.

## Clustering

```text
RabbitMQ CLUSTER → multiple RabbitMQ nodes working together as one logical broker:
  → nodes share metadata (queues, exchanges, bindings, users)
  → distributes connections and load across nodes
  ⚠️ by default, a queue lives on ONE node → if that node fails, the queue is unavailable
    (clustering alone doesn't make queues highly available → need replication)
```

## Replikované fronty (pro HA)

```text
To make queues survive node failure, REPLICATE them across nodes:
QUORUM QUEUES (modern, recommended) → replicated via a consensus (Raft) algorithm:
  → data replicated to multiple nodes; a majority must agree → consistent, durable, HA
  → if a node fails, another replica serves the queue → no message loss
MIRRORED QUEUES (classic, older) → queue mirrored to other nodes (being deprecated in
  favor of quorum queues)
→ replicated queues survive node failures (the key to HA)
```

## Úvahy o HA

```text
✓ Use QUORUM QUEUES for HA (modern, consensus-based, reliable)
✓ Cluster across multiple nodes/machines (and consider zones for resilience)
✓ LOAD BALANCER in front for client connections (route to available nodes)
✓ trade-off: replication adds overhead (performance cost) for availability/durability
✓ Network partitions → handle split-brain (partition handling strategies)
```

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

Pochopení, jak funguje vysoká dostupnost v RabbitMQ, je cenné, protože **HA je důležitá pro spolehlivé produkční nasazení RabbitMQ**, takže se jedná o relevantní operační znalosti.

Produkční messaging často nemůže tolerovat výpadky nebo ztrátu zpráv v důsledku selhání uzlů, čímž se HA stává důležitou.

Pochopení **clusteringu** – více RabbitMQ uzlů pracujících společně jako jeden logický broker (sdílení metadat, distribuce zátěže) – je základem, ale s důležitou výhradou, že **clustering sám o sobě nezajistí vysokou dostupnost front** (standardně fronta existuje na jednom uzlu, takže pokud tento uzel selže, fronta není dostupná – běžné nepochopení).

Pochopení **replikovaných front** je klíčem k HA: **quorum fronty** (moderní, doporučovaný přístup, replikující data mezi uzly prostřednictvím konsenzu/Raft, takže se musí shodovat majoritou, poskytují konzistenci, trvanlivost a HA, s další replikou obsluhující frontu, pokud uzel selže – bez ztráty zpráv) a zrcadlené fronty (klasický, starší přístup, kterého se upouští ve prospěch quorum front).

Pochopení, že **replikované fronty přežijí selhání uzlů** (skutečný mechanismus pro HA, nad rámec pouhého clusteringu), je zásadní.

Pochopení **úvah o HA** – použití quorum front pro HA, clustering mezi uzly/stroji (a zónami), použití load balanceru pro klientská připojení, kompromis (náklady replikace na výkon za dostupnost/trvanlivost) a řešení síťových rozdělení (split-brain) – odráží stavbu produkčního RabbitMQ s HA.

Klíčová myšlenka je, že HA vyžaduje replikované fronty (quorum fronty), nikoli jen clustering.

Protože je HA důležitá pro spolehlivý produkční RabbitMQ (přežití selhání uzlů bez ztráty zpráv) a vyžaduje pochopení, že clustering sám o sobě nestačí (replikované quorum fronty jsou klíčové), a protože pochopení HA je relevantní operační znalost, pochopení, jak funguje vysoká dostupnost v RabbitMQ, je cenná, prakticky relevantní znalost – důležitá pro spolehlivý produkční RabbitMQ, objasnění, že HA vyžaduje replikované fronty (moderní quorum fronty) nikoli jen clustering, a odraz operačních znalostí potřebných ke spolehlivému provozu RabbitMQ s vysokou dostupností.