故障转移状态机是通过可验证、可追踪的状态规则控制切换节奏、边界与安全前提的机制，包含状态定义、事件驱动转换、动作绑定三层次；状态反映节点实时能力（如init/wait_primary/catchingup），事件触发严格校验后转换（如心跳超时启动选举），动作在转换时执行并固化于代码；无状态服务可简化为健康判定与流量调度。
故障转移状态机不是简单地“换一台机器顶上”，而是用一套可验证、可追踪的状态规则，控制整个切换过程的节奏、边界和安全前提。理解它，关键在于看清三个层次：节点当前处在什么状态、什么事件能触发变化、变化后系统要执行哪些动作。
状态是切换的起点，不是标签
状态代表系统对节点能力与角色的实时认知，比如：
- init：Monitor刚看到这个节点，还不知道它能不能当主库，也没确认它有没有同步能力
- wait_primary：主库已识别出备库存在，也配好了访问权限，但还在等备库完成初始同步；一旦备库失联或同步卡住，主库会主动进入这个状态，同时暂停强同步，避免事务阻塞
- catchingup：备库正在追赶主库日志，LSN还没对齐，不能参与投票或接管服务
这些状态不是静态快照，而是动态反映系统是否满足某个角色的前提条件。例如，一个节点标为“secondary”，不代表它随时能升主——只有当它的状态变成“ready”且LSN与主库一致时，才真正具备接管资格。
事件驱动转换，而非定时轮询
状态变化由明确事件触发，不是靠猜测或延时等待：
- 主库心跳超时 → Monitor将主库标记为unreachable，启动重新选举流程
- 备库完成WAL同步并报告一致LSN → Monitor将其状态从catchingup升级为ready
- 人工执行
pg_autoctl perform failover→ 强制触发状态机进入demote_primary → promote_candidate路径
每个事件都对应一段严格校验逻辑。比如检测到主库不可达后，Monitor不会立刻切，而是先检查其他节点是否健康、是否有足够多数派、是否满足数据一致性水位（如最小同步副本数），全部通过才推进下一步。
动作绑定在转换上，确保每步可审计
状态跳转本身不做事，真正的操作发生在“转换”环节：
- 从primary → demoted：执行
pg_ctl promote -D $PGDATA前，先写入切换日志、关闭监听端口、通知客户端连接中断 - 从secondary → primary：先校验自身WAL位置，再重放剩余日志，最后才开放写入，并向Monitor注册新角色
- 从wait_primary → primary：只在确认至少一个备库达到ready后才允许，否则停留在该状态防止脑裂
所有动作都在源码中固化，比如src/monitor/group_state_machine.c里每个transition_to_XXX()函数，既做状态更新，也调用对应的系统命令和通知逻辑，避免人为遗漏或顺序错误。
无状态服务的简化路径
对于模型推理、API网关这类无状态服务，状态机可以大幅精简：
- 不需要跟踪数据一致性，状态只需表达“健康”或“不健康”
- 事件主要是HTTP探针失败、GPU显存溢出告警、进程退出信号
- 动作就是更新路由表、摘除实例、触发部署脚本拉起新副本
这种设计把复杂性从“数据同步”转移到“健康判定”和“流量调度”，更轻量，也更容易测试和回滚。
