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:
-
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. -
Querying State and Snapshots:
applied_state
allow querying the current state of the state machine. -
Snapshot Handling: Through methods like
get_snapshot_builder
,begin_receiving_snapshot
,get_current_snapshot
andinstall_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
.