Skip to content

Latest commit

 

History

History
94 lines (73 loc) · 5.21 KB

Code-Overview.md

File metadata and controls

94 lines (73 loc) · 5.21 KB
Raw

Code-Overview

This simulation provides a basic implementation of the RAFT algorithm. It includes a RAFTServer class that represents each server in the cluster, a LogEntry class to model log entries, and a simple main class for running the simulation.
Here you can find a brief description of all the classes and their attributes and methods:

RAFTServer Class:

Represents a Server in the RAFT-Cluster. Key components include:

Enum defines the possible states of a Server:

  • FOLLOWER: A server that is following a leader.
  • CANDIDATE: A server that is running for leadership.
  • LEADER: A server that leads the cluster and manages log replication.

Fields:

  • state: Current state of the server (FOLLOWER, CANDIDATE, LEADER).
  • term: Logical time period used to maintain consistency across the distributed system.
  • votes: Number of votes received by the server during an election.
  • id: Unique identifier for the server.
  • log: List of log entries.
  • executor: ScheduledExecutorService for handling time-based tasks.
  • electionFuture: Reference to a scheduled election task.

Methods:

  • getRandomTimeout(): Generates a random timeout value within a specified range for election timeouts.
  • start(): Initializes the server, sets its state to FOLLOWER, and schedules an election timeout.
  • startElection(): Transitions the server to CANDIDATE state, initiates an election by requesting votes, and schedules the next election timeout.
  • requestVote(RAFTServer candidate): Processes a vote request from another server, updates its term, and grants a vote if eligible.
  • receiveVote(): Increments the vote count and transitions to LEADER state if a majority of votes is received.
  • becomeLeader(): Transitions the server to LEADER state, starts sending heartbeats, and replicates log entries to followers.
  • sendHeartbeats(): Sends heartbeat messages to all follower servers to maintain leadership and prevent new elections.
  • receiveHeartbeat(RAFTServer leader): Updates the server's term and state if it receives a heartbeat from a server with a higher term.
  • replicateLogEntries(): Simulates the replication of log entries from the leader to follower servers.
  • addServer(RAFTServer server): Adds a server to the cluster.
  • shutdown(): Shuts down the executor service.

LogEntry Class:

Models a log entry in the RAFT system:

Fields:

  • id: Unique identifier for the log entry.
  • operation: Description of the operation represented by the log entry.
  • Constructor: Initializes a log entry with an operation.

Methods:

  • toString() : Provides a string representation of the log entry for display purposes.

main Class:

Contains the main method for running the simulation:

  • Creates Instances: Initializes three servers (s1, s2, s3).
  • Adds Servers to Cluster: Adds servers to the RAFT cluster.
  • Starts Servers: Starts each server.
  • Runs Simulation: Allows the simulation to run for 15 seconds.
  • Shutdown: Shuts down the executor services for all servers

Testing Highlights: Initial Server Startup

Example Image

All three servers (Server 1, Server 2, and Server 3) have initialized and started in the FOLLOWER state. This is the default state for all servers when the system starts, where they wait for a leader to be elected.

Testing Highlights: Election and Leader Transition

Example Image

  • Election Start: Server 2 initiates an election for term 1.
  • Vote Request: Server 1 receives a vote request from Server 2 for term 1 and updates its term to 1, changing its state to FOLLOWER.
  • Vote Granting: Server 2 receives the necessary votes (including its own) and is elected as the leader for term 1.
  • Heartbeat Sending: Server 2 begins sending heartbeats to other servers to assert its leadership.
  • State Change: Server 3 receives the heartbeat from Server 2 and changes its state to FOLLOWER.
  • Log Replication: Log entries created by Server 2 are replicated to both Server 1 and Server 3.

Testing Highlights: Re-Election and New Leader

Example Image

  • Election Start: Server 3 initiates an election for term 2.
  • Vote Request: Server 1 receives a vote request from Server 3 for term 2 and updates its term to 2, changing its state to FOLLOWER.
  • Vote Granting: Server 3 receives the necessary votes and is elected as the new leader for term 2.
  • Heartbeat Sending: Server 3 begins sending heartbeats to other servers to assert its leadership.
  • State Change: Server 2 receives the heartbeat from Server 3 and changes its state to FOLLOWER.
  • Log Replication: Log entries created by Server 3 are replicated to both Server 1 and Server 2.

All the code in this repository is commented to provide additional information and context. If you need any details or explanations, please refer to the comments within the code. For seeing an implementation which has been enhanced to simulate real-world distributed systems check RAFT-Algorithm-Full-Features.