Cluster Component Model
Aeron Cluster is a Raft-based consensus system, designed host application in the form of finite state machines. The intention is to provide a system for high performance fault tolerant services.
Below is a high-level diagram of some of the main components in play when a cluster is running normally (without faults). To simply the image some components of Aeron have been hidden (media driver, client, and archive). This doesn't include the components that come into play during the election cycle.
Aeron Cluster, more so than any other part of Aeron has a lot of moving parts that need to co-ordinate in order to provide the desired functionality.
AeronCluster is the main entry point for clients that submit messages into the cluster. Its offer method call directly onto a publication for the ingress channel into the cluster. It will also maintain a subscription receiving response messages from the cluster.
The Consensus Module is the core part of Aeron Cluster, being responsible for ensuring that nodes within the cluster are in agreement and allowing client application logic to progress appropriately.
The entry point for messages coming into the cluster. It is constructed by the ConsensusModuleAgent and is responsible for decoding the input messages from the ingress channel before passing them onto the ConsensusModuleAgent.
This is the nerve centre for Aeron Cluster all of the application and consensus logic passes through this component. It is responsible for triggering and running Elections at the appropriate time. It will construct publications for consensus (ConsensusPublisher) and application (LogPublisher) traffic for sending data onto the other instances of the Consensus Module with the cluster. In turn it will handle traffic from other nodes and react to it appropriately.
This is the channel that creates the single linearised log of application messages that is central to the Raft algorithm. Constructed by the ConsensusModuleAgent, once the Election is closed, the leader will add a publication and start recording it to Aeron Archive, then inject the publication into the LogPublisher. All application messages received by the ConsensusModuleAgent (via the IngressAdapter) will be passed onto this publisher to storing to disk and replication to the other nodes in the cluster.
This is the receiving side of the log channel. Constructed by the ConsensusModuleAgent, once the Election is closed, the followers will add a subscription to the log channel as well as setting up a remote recording of the log channel to ensure that it has a copy of the data from the leader stored to disk. Messages received via the log channel are forwarded onto the ConsensusModuleAgent. Because this is only running on the followers, the callbacks on the ConsensusModuleAgent are all named onReplayXXX, because that is effectively the behaviour of a follower node, it is replaying the data from the leader. The LogAdapter is also used during the recovery portion of the Election process.
The ConsensusPublisher is constructed for both leaders and followers and used for passing all of the traffic used to ensure that the nodes have reached consensus before allowing the application to progress. The two most significant events are CommitPosition and AppendPosition. The followers will send an AppendPosition event to the leader as the local copy of the application log appended to. The leader will send CommitPosition message once a quorum between the nodes has been reached with regards to what data has be safely recorded. The nodes will also update a CommitPosition counter either when quorum is detected (leader) or on receipt of the CommitPosition message (follower).
The ConsensusAdapter is the receiver side of the consensus channel and decodes the messages for forwarding onto the ConsensusModuleAgent.
The clustered service is where the application logic runs. An interested aspect of Aeron's Raft design is that many of the components run concurrently. This reduces the possibility of having the application logic and the ConsensusModuleAgent logic interfering with each other.
The ClusteredServiceContainer uses a variation of the LogAdapter to read the same stream of log messages being received by the ConsensusModuleAgent. It runs on a subscription that is set up as a spy of the incoming log channel, removing and data copies for moving data between the ConsensusModule and the ClusteredService. It is bounded because the log may have data in it that the cluster is yet to come to agreement that it should be processed by the application logic. The bound is handled by have the ClusteredServiceAgent poll the CommitPosition counter owned by the ConsensusModule.
The main component within the ClusteredServiceContainer. It takes an instance of a ClusteredService that represents the users application logic and passes the messages it receives from the LogAdapter onto the ClusteredService.
An interface that is implemented by a user to contain their application logic.
A session is created for each client that connects to the cluster. The application logic can use the session to send response messages back to specific client using it's offer method. Those messages will be forwarded to the ConsensusModuleAgent to be published to the egress channel back to the client.