第2章 状态管理架构总览：分层模型、模块职责、数据流与控制流分离

2.1 本章边界与分层目标

状态管理架构的核心在于将会话状态的创建、存储、恢复与业务逻辑解耦。本章从系统架构视角定义三层模型：接入层、会话状态层、持久化层，明确每一层的边界、组件职责，以及数据流与控制流的分离原则。分层目标包括：

• 隔离变化：任意层的内部实现替换不影响其他层。
• 提升可测试性：每层可独立模拟与验证。
• 支持横向扩展：无状态接入层可随意伸缩，有状态层通过分片/复制扩展。
• 明确信任链路：控制流仅通过安全通道传递，数据流受速率与容量限制。

2.2 分层模型与组件职责

2.3 数据流与控制流分离设计

分离原则确保系统在高吞吐下保持可预测性：

• 数据流：会话数据（状态快照、增量补丁）在会话状态层 ↔ 持久化层之间异步批量传递，使用背压机制防过载。
• 控制流：会话创建、迁移、过期等元数据变更通过独立通道（消息队列或 RPC）传递，优先级高于数据流。
• 信任链路：控制命令必须携带签名或认证令牌，数据流仅通过安全 TLS 通道但不要求逐包验证。

2.4 信任链路与安全边界

分层模型隐式定义了信任域：

• 接入层被视为不可信区域，必须对所有请求进行身份验证、限流、防重放。
• 会话状态层为半可信区域，只信任来自接入层且通过签名的控制命令（如会话创建请求）。
• 持久化层为可信区域，仅接受会话状态层内部 RPC 调用，不对外暴露任何端口。

2.5 选型权衡

2.6 风险点

• 状态雪崩：会话状态层缓存失效时，大量回源请求压垮持久化层。对策：本地缓存 + 限流 + 渐进式淘汰。
• 脑裂：会话状态层多副本间数据不一致，导致会话冲突。对策：强制使用 Quorum 读写 + 版本向量。
• 死锁：控制流与数据流共用同一线程池时，可能互相等待。对策：分离线程池或使用独立 I/O 队列。
• 数据倾斜：一致性哈希分片不均匀导致热点。对策：虚节点 + 定期 rebalance 触发。

2.7 落地步骤

1. 定义会话标识与元数据协议：确定 格式（JWT / UUID）、过期策略、版本号字段（推荐单调递增 Lamport 时钟）。
2. 搭建接入层：配置 API 网关，实现无状态路由，仅透传 到会话状态层。
3. 部署会话状态层：启动 Redis Cluster（至少 3 节点），配置一致性哈希分片策略，实现本地缓存 TTL。
4. 实现持久化层接口：选择 TiKV 或 RocksDB，定义 WAL 写入格式，支持批量快照和增量回放。
5. 对接控制流通道：使用 gRPC 或 Kafka Topic 传递会话创建/销毁/迁移命令，接入层仅发控制命令，不包含全量数据。
6. 建立数据流背压：在会话状态层设置写入队列上限，到达阈值时降级为仅缓存不持久化，待队列腾空后再写入。
7. 集成混沌测试：模拟节点宕机、网络分区、请求突发，验证分层隔离是否生效。

2.8 验收标准