本文目录导读：
状态机复制是分布式系统中实现容错和一致性的核心思想，它由 Leslie Lamport 等人在 20 世纪 70 年代末提出，是 Paxos、Raft 等共识算法的理论基础。
它的核心思想可以概括为：
如果多个副本（节点）从相同的初始状态出发，并且以相同的顺序执行相同的一系列操作（指令），那么它们最终一定会达到相同的最终状态。
核心原理
状态机复制将分布式系统抽象为两个部分：
- 确定性状态机：这是一个逻辑模型，给定一个状态
S和一个输入操作Op，其输出Out和下一个状态S‘是唯一确定的。S' = execute(S, Op)。- 关键：确定性 是前提，如果同一个操作在不同节点上产生不同结果（依赖于本地时间、随机数或未同步的全局变量）,那么状态机模型就会被破坏。
- 复制日志：这是一个所有节点都需要达成一致的、有序的操作序列。
[Op1, Op2, Op3, ...]
工作流程：
- 客户端发送请求：客户端向集群发送一个操作（“将 X 的值加 1”）。
- 共识模块：集群中的一个节点（通常是领导者）负责将客户端的操作 追加到自己的日志中，它通过一个共识算法（如 Paxos 或 Raft）将这个日志条目广播给其他节点。
- 日志复制：只有当集群中的大多数（法定人数，quorum）节点都确认收到了该日志条目并将其安全地存储后，该条目才被视为已提交。
- 执行：一旦日志条目被提交，每个节点都会 按照日志顺序（从日志头部开始）将该操作应用到自己的本地状态机上。
- 返回结果：执行完成后,节点将执行结果返回给客户端。
逻辑架构图
graph TD
subgraph 客户端
C[客户端]
end
subgraph 复制状态机集群
subgraph 节点A
A_Log[ replicated log<br>1. 写 x=3<br>2. 写 y=5<br>3. 读 z]
A_State[ State Machine<br>X:3, Y:5]
end
subgraph 节点B
B_Log[ replicated log<br>1. 写 x=3<br>2. 写 y=5<br>3. 读 z]
B_State[ State Machine<br>X:3, Y:5]
end
subgraph 节点C
C_Log[ replicated log<br>1. 写 x=3<br>2. 写 y=5<br>3. 读 z]
C_State[ State Machine<br>X:3, Y:6]
end
end
C -->|“写 x = 3”| 共识模块
共识模块 -->|1. 追加日志| A_Log
共识模块 -->|2. 复制日志| B_Log
共识模块 -->|3. 复制日志| C_Log
A_Log -->|按序执行| A_State
B_Log -->|按序执行| B_State
C_Log -.->|状态不一致| C_State
图中问题：假设节点C因为某种原因(如网络延迟、错误执行)导致其状态机对第3个操作(读z)产生了不同的结果(X:3, Y:6)，这就违反了状态机复制的核心原则，在正确实现中，当节点C发现自己的状态与领导者的不一致时(通过日志对比)，它会删除自己的不一致日志,从领导者处同步正确的日志并重新执行。
类比：银行账户
假设有三个银行分行（节点）,要共同维护客户的存款余额。
- 状态：客户张三的余额（100元）。
- 操作：存款 +50、取款 -20、转账 -30。
- 日志：一份所有分行都认同的交易流水。
正确流程（状态机复制）：
- 张三在分行A（领导者）存款50元，分行A在流水单上写下：“[第101条] 存款：+50”。
- 共识算法（比如通过微信群里喊话）确保分行B和分行C也记录下：“[第101条] 存款：+50”。
- 所有分行（A、B、C）读取流水单，从第1条开始执行，执行完第101条后，所有分行的电脑屏幕上都显示：张三余额 = 150元。
错误流程（未遵守状态机复制）：
- 如果分行C因为故障，漏掉了第101条流水，直接从第102条开始执行，那么当第102条是“取款100”时：
- 分行A和B（基础余额150元）：余额变为50元。
- 分行C（基础余额100元）：余额变为0元。
- 系统不一致,出现严重错误。
为什么需要共识算法？
状态机复制本身是一个概念模型，它没有解决一个核心工程问题：如何保证所有节点以完全相同的顺序（日志顺序）看到完全相同的操作？
在分布式系统中，节点可能宕机、网络可能延迟或分区，共识算法（如 Paxos 和 Raft）正是专门用来解决这个难题的组件：
- 领导者选举：确保在一个任期内只有一个节点被授权追加日志条目,避免日志分叉。
- 日志复制：保证日志条目可靠地复制到多数节点。
- 安全性：保证已经提交的日志条目在任何节点上都不会被修改或丢失；保证日志的顺序是全局一致的。
关系总结：
- 状态机复制是“做什么”（最终状态一致）。
- 共识算法是“怎么做”（日志排序与同步）。
经典应用
几乎所有的强一致性分布式系统都基于这个模型：
- ZooKeeper / etcd / Consul：用于分布式协调、服务发现、配置管理。
- 状态：关键值（key-value）数据。
- 操作：Create、Set、Delete。
- 共识：Zab（ZooKeeper）/ Raft（etcd、Consul）。
- Chubby：Google 的分布式锁服务，基于 Paxos。
- Google Spanner / CockroachDB / TiDB：全球分布式数据库。
- 状态：关系型数据表。
- 操作：SQL 读写。
- 共识：Paxos 或 Raft。
- Kafka（高版本）：使用 KRaft（基于 Raft）替代 ZooKeeper 进行元数据管理。
状态机复制是构建高可用、强一致性、线性一致性（线性izability） 分布式系统的核心工程模式，它将复杂的容错问题转化为一个更简单的日志复制与排序问题，从而将一个不可靠的分布式系统抽象为单个可靠的、确定性的逻辑单元。
关键点回顾：
- 确定性是基石。
- 日志顺序决定一切。
- 共识算法是实现工具。
- 多数派（法定人数，quorum） 是容错的关键。
