SOFAJRaft Documentation

repository·master·Indexed 25 days ago

https://github.com/sofastack/sofa-jraft

A high-performance Java implementation of the RAFT consensus algorithm optimized for high-load scenarios via MULTI-RAFT-GROUP support. It provides core distributed systems capabilities including leader management, log replication, snapshotting, and cluster membership management. The library includes an embedded distributed KV storage implementation and supports linearizable reads via ReadIndex or LeaseRead. It has passed Jepsen consistency verification tests.

Tokens
8.9K
Snippets
3
Records
76
Agent score
86%

What's inside SOFAJRaft

  1. Overview of SOFAJRaft

    master

    SOFAJRaft is a production-grade, high-performance Java implementation of the RAFT consensus algorithm. It supports MULTI-RAFT-GROUP and is designed for high-load, low-latency scenarios. It handles complex RAFT-related technical challenges, allowing developers to focus on their business logic. Key features include:

    • Leader election (including priority-based semi-deterministic election).
    • Log replication and recovery.
    • Read-only members (Learner role).
    • Snapshotting and log compaction.
    • Online cluster configuration changes (adding, removing, or replacing nodes).
    • Active Leader changes for maintenance or load balancing.
    • Tolerance for both symmetric and asymmetric network partitions.
    • Fault tolerance (minority failures do not affect availability; manual recovery available for majority failures).
    • Efficient linearizable reads via ReadIndex and LeaseRead.
    • Pipelined replication.
    • Built-in performance metrics based on the Dropwizard Metrics library.
    • Jepsen consistency verification passed.
    • Includes an embedded distributed KV storage implementation.
  2. Key Features of SOFAJRaft

    master

    SOFAJRaft provides several core distributed systems capabilities:

    • Leader Management: Leader election (including priority-based semi-deterministic election) and leader transfer mechanisms for reboots or load balancing.
    • Data Consistency: Log replication, recovery, snapshotting, log compaction, and linearizable reads (via ReadIndex or LeaseRead).
    • Cluster Management: Membership management (adding, removing, or replacing nodes) and support for read-only members (learner).
    • Fault Tolerance: Symmetric and asymmetric network partition tolerance, and manual cluster recovery for majority failure scenarios.
    • Performance & Observability: Replication pipelines and rich performance statistics based on Metrics.
    • Verification: Passed Jepsen consistency verification tests.
    • Storage: Includes an embedded distributed KV storage implementation.
  3. Upgrade to LogitLogStorage via Raft Peer Changes

    master

    You can perform a smooth hot upgrade to LogitLogStorage by leveraging Raft's membership change capabilities. This method avoids direct storage migration by letting new nodes sync data from the leader.

    Steps for Hot Upgrade:

    1. Start with an existing cluster (e.g., nodes A, B, C) running the old version.
    2. Use CliService.changePeers to add new nodes (e.g., D, E, F) running the new version. These nodes will automatically replicate the existing logs from the current Leader.
    3. Once the new nodes are caught up, use CliService.transferLeader to move the leadership to one of the new nodes (e.g., node D).
    4. Shut down the old nodes (A, B, C).
  4. Upgrade to LogitLogStorage via HybridLogStorage

    master

    To upgrade from the legacy RocksDBLogStorage to the new Java-based LogitLogStorage without data loss, use the HybridLogStorage implementation. This hybrid storage manages both old and new storage engines simultaneously.

    Upgrade Process:

    1. Set the default service factory to LogitLogJRaftServiceFactory in your node options.
    2. Upon startup, HybridLogStorage calculates a thresholdIndex (the last index in RocksDBLogStorage + 1).
    3. As Raft snapshots are taken, the truncateIndex (the point where old logs are removed) will eventually exceed the thresholdIndex.
    4. Once the truncateIndex is beyond the thresholdIndex, the old RocksDBLogStorage is no longer needed and can be safely shut down.
    nodeOptions.setServiceFactory(new LogitLogJRaftServiceFactory());
  5. Run client benchmarks using client_benchmark_start.sh

    master

    The client_benchmark_start.sh script is used to launch client benchmark processes for SOFAJRaft. It automatically calculates JVM memory settings based on the system's total memory and requires Java 1.8. The script runs the benchmark in the background using nohup and redirects output to client_stdout.

    Usage:

    ./client_benchmark_start.sh <arg1> <arg2> <arg3> <arg4> <arg5> <arg6> <arg7> <arg8>

    Requirements:

    • Java Version: Must be Java 1.8. The script will exit with an error if other versions are detected.
    • Environment: Requires $JAVA_HOME to be set correctly.
    • Arguments: The script accepts up to 8 positional arguments which are passed directly to the com.alipay.sofa.jraft.benchmark.BenchmarkBootstrap class.
  6. Run server benchmarks using server_benchmark_start.sh

    master

    The server_benchmark_start.sh script is used to launch SOFAJRaft server benchmark instances in the background. It automatically calculates optimal JVM memory settings based on the system's total available memory and requires Java 1.8.

    To run a benchmark server, execute the script from the jraft-example/bin/ directory, providing the required positional arguments for the benchmark configuration.

    Usage:

    ./server_benchmark_start.sh <arg1> <arg2>

    Requirements:

    • Java Version: Must be Java 1.8. The script will exit with an error if other versions are detected.
    • Environment: Requires JAVA_HOME to be set correctly.
    • Output: Standard output and error are redirected to server_stdout in the execution directory.
    • Execution Mode: The process is started using nohup in the background.
  7. Configure Replicator Pipeline for AppendEntries

    master

    SOFAJRaft supports a replication pipeline mode to optimize AppendEntries requests. When enabled, the AppendEntriesRequestProcessor uses a specialized PeerExecutorSelector and SequenceRpcRequestClosure to handle requests in a pipelined fashion, ensuring responses are sent in the correct sequence.

    To enable this behavior, ensure that isReplicatorPipeline() is set to true in your RaftOptions.

    Note: When pipeline mode is active, the system tracks the number of pending responses. If the number of pending responses exceeds maxReplicatorInflightMsgs (configured in RaftOptions), the connection to that peer will be closed to prevent resource exhaustion.

  8. LogitLogStorage File Format Specifications

    master

    The LogitLogStorage system uses two primary file types: IndexFile and SegmentFile.

    IndexFile

    Stores fixed-size index entries (10 bytes each). An entry consists of:

    • Magic byte: [0x57] (1 byte)
    • Index type: Indicates if the log is a regular log or a Conf type log (1 byte)
    • Offset: The entry's offset relative to the start of the file (4 bytes)
    • Position: The physical position of the log in the SegmentFile (4 bytes)

    SegmentFile

    Stores the actual log data. An entry consists of:

    • Magic bytes: [0x57, 0x8A] (2 bytes)
    • Data length: The size of the log data (4 bytes)
    • Data: The actual log payload (variable bytes)