Kako funkcionira klasteriranje u RabbitMQ-u?

Question

Accepted Answer

**Klasteriranje** povezuje više RabbitMQ čvorova u jedan logički broker — za skalabilnost i (s repliciranima redovima) visoku dostupnost. Razumijevanje klasteriranja i njegovih nijansi važno je za skaliranje i pouzdano upravljanje RabbitMQ-om.

## Što je klaster

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

## Redovi u klasteru (važna nijansa)

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

## Razmatranja klasteriranja

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

## Zašto je to važno

Razumijevanje kako funkcionira klasteriranje u RabbitMQ-u je vrijednosno znanje za starije razine jer **je klasteriranje važno za skaliranje i HA**, ali ima nijansi koje moraju biti razumljene za pouzdanu operaciju.

Klasteriranje povezuje više čvorova u jedan logički broker, važno za produkcijski RabbitMQ.

Razumijevanje **što je klaster** — više čvorova koji djeluju kao jedan logički broker, dijele metapodatke između čvorova, s klijentima koji se spajaju na bilo koji čvor i distribucijom opterećenja — pojašnjava osnovni koncept (skaliranje kapaciteta konekcija i distribucija opterećenja).

Kritično je razumijevanje **važne nijanse o redovima u klasteru** — da se podatke reda po zadanoj vrijednosti **nalaze na jednom čvoru** (ostali čvorovi znaju metapodatke ali rutiraju do vlasničkog čvora), pa ako taj čvor padne red i njegove poruke nisu **dostupne**, što znači da **samo klasteriranje NE čini redove visoko dostupnima** — je bitno, jer je to česta, ozbiljna zabluda (люди pretpostavljaju da klasteriranje daje HA, ali ne daje za podatke redova).

Razumijevanje da **HA zahtijeva replizirane redove (quorum redovi)** koji replikuju podatke između čvorova je ključni zaključak.

Razumijevanje **razmatranja klasteriranja** — korištenje quorum redova za HA, rukovanje **mrežnim particijama** (split-brain rizik, zahtijevajući strategiju rukovanja particijom), čuvanje čvorova na pouzdanoj niskolatentnoj mreži (klasteriranje osjetljivo na mrežne probleme), korištenje load balancera za konekcije, i korištenje **federacije/shovel-a za geosdistribuciju** (ne klasteriranje kroz visokolatentne linkove — važna arhitektonska točka) — odražava ispravan rad klastera.

Ete nijanse (klasteriranje ≠ HA redova, rukovanje particijom, osjetljivost mreže, geodistribucija preko federacije) važne su za pouzdano klasteriranje.

Pošto je klasteriranje važno za skaliranje i HA ali ima ključnih nijansi (posebno da samo klasteriranje ne čini redove HA-om — trebaju replicirani quorum redovi, plus rukovanje particijom i osjetljivost mreže), i pošto je razumijevanje ovih važno za pouzdanu operaciju, razumijevanje kako funkcionira klasteriranje u RabbitMQ-u je vrijednosno znanje za starije razine — važno za skaliranje i HA, s kritičnom nijansom da samo klasteriranje ne pruža HA redova (zahtijevajući quorum redove), plus razmatranja rukovanja particijom i geodistribucije, i odražavajući operativno znanje potrebno za pouzdano klasteriranje RabbitMQ-a.