Stores for Message Broker
This topic presents information for architects and administrators about using stores to implement a message broker.
The default message broker uses built-in configuration values, which administrators do not need to configure explicitly (see "FTL Server: Message Broker Default Operation"). Alternatively, administrators may explicitly configure a message broker to meet application requirements.
Topology
When using a store for message broker functionality, the store is an intermediary hop between publishing and subscribing applications. In the following diagram, notice the absence of any direct path. The store is the only path from the publishing endpoint to the subscribing endpoints.
Topics and Queues
Message brokers can organize messages in topics or queues.
A shared durable is equivalent to a queue. Green arrows in the diagram indicate delivery of each message to exactly one of the three subscribers.
A standard durable is equivalent to a topic. Blue arrows in the diagram indicate delivery of each message to both subscribers.
Replication
Message broker stores can be replicated or non-replicated.
Replicated stores provide fault-tolerance through redundancy. (However, replication requires a cluster of three or more message brokers.)
In contrast, when a non-replicated store receives messages from publishers, the message broker does not replicate them to other message brokers in the cluster. In using non-replicated storage, message brokers implicitly risk lost messages (for example, if the broker exits with undelivered messages). In exchange, non-replication reduces consumption of I/O bandwidth, process memory, and CPU cycles.