Versions Compared

Old Version 4

changes.mady.by.user Alan Conway

Saved on

compared with

New Version Current

changes.mady.by.user Alan Conway

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Definitions

There are two very different reasons to cluster:

  • Reliability/Fault Tolarance
    • Cluster members replicate state.
    • If one member fails, clients can fail-over to another.
  • Scalabilty/throughput/load balancing:
    • Distribute large work load across multiple brokers for higher throughput.

Its important not to confuse the two goals. Note that a reliable cluster will be LESS scalable and performant than even a single broker - replication is extra work on top of normal processing. There is alsoThe topic is being broken up into three sections:

  • Federation (a set of distributed exchanges and queues, seperately managed and wired together)
  • Clustering (a set of distributed exchanges and queues managed as a single entity)
  • HA / Fault tolarance (the ability for exchanges and queues, clustered, federated, or isolated to replicated important state to a backup (failover partner))
  • Failover (the ability for a client to reconnect to the failover partner)

Use Cases

Abstract Use Cases

Design notes

It's not clear where to draw the line between federation and clustering for scalability.

Reliability clustering is orthogonal to scalability clustering/federation, which means they can be combined.
Just replace the individual brokers in your federation or scalability cluster with reliable broker clusters
and you have a reliable and scalable system.

Requirements/Use Cases

Design notes

Related reading