Module openraft::docs::components::state_machine

source ·
Expand description

RaftStateMachine serves as the core API for managing the state machine and snapshot functionalities. It directly ties the concepts of state management and snapshotting, acknowledging that snapshots are often simply persisted states of the state machine.

§Key Responsibilities

The RaftStateMachine encapsulates several critical responsibilities:

  1. Log Application: It requires an implementation of the apply method, where the state machine processes and applies committed log entries. This method is central to maintaining the state machine’s integrity and ensuring that all state transitions are based on the replicated and committed log entries.

  2. Querying State and Snapshots: applied_state allow querying the current state of the state machine.

  3. Snapshot Handling: Through methods like get_snapshot_builder, begin_receiving_snapshot, get_current_snapshot and install_snapshot defines a comprehensive approach to managing snapshots. These methods cover creating snapshots, handling incoming snapshot data from the leader, and installing snapshots to bring the state machine to a specific state.

§State Management in Raft State Machines

  • State Reversion and Recovery: The state machine in the Raft application is typically an in-memory component. Upon startup, the state machine may revert to a previous state. This setup is generally acceptable because the combination of a persistent snapshot and the Raft logs provides sufficient information to reconstruct the state. This process involves first rebuilding the state machine from the snapshot and then reapplying any logs that are not included in the snapshot.

    Afterwards, Raft log entries are applied to update the state machine to its current state.

  • Distinct Management of Membership and Normal Logs: Within the state machine, the state of membership configuration logs and the state of normal logs are managed separately, though they are stored together. These can be thought of as two distinct sections.

  • Membership Config State Beyond the Last Applied: It is acceptable for the membership to return with a log ID greater than the last applied log ID, provided that the corresponding Raft logs have not been purged and can thus be reapplied to the state machine. Upon startup, the most recent membership configuration is loaded by scanning the logs starting from the last-applied-log-id.