📚 课程目录第3章架构设计原则

3. 架构设计原则：CAP理论在调度系统中的应用、最终一致性设计、无状态化改造思路

调度系统的高可用，说白了就是跟「不确定性」做斗争。网络会抖、机器会挂、磁盘会满，你设计的调度器必须在这种环境下还能稳定产出结果。这一章，我结合自己踩过的坑，聊聊三个核心原则：CAP 怎么选、一致性怎么做、无状态怎么改。

3.1 CAP 理论：调度系统到底该放弃什么？

CAP 理论大家都熟——一致性（C）、可用性（A）、分区容错性（P），三者最多同时满足两个。但在调度系统里，这个选择题其实有固定答案。

调度系统必须选 AP。为什么？

分区容错性（P）是必选项：调度器跨机房、跨集群部署，网络分区是常态。不选 P，分区发生时整个系统就废了。
可用性（A）是业务底线：调度任务不能停。哪怕数据暂时不一致，调度器也得继续派发任务。
一致性（C）可以妥协：但要注意，不是完全放弃，而是「最终一致」。

核心结论：调度系统是典型的 AP 系统，通过最终一致性来弥补 C 的缺失。

我在项目中遇到过这样的场景：两个调度节点同时认为自己是 Leader，都开始派发任务。结果同一个任务被重复执行了两次。这就是放弃强一致性带来的代价。但业务上，重复执行比任务不执行要好——大不了加个幂等去重。

3.2 最终一致性设计：从「强一致」到「最终一致」的妥协

最终一致性不是「不管了」，而是「允许短暂不一致，但保证最终收敛」。调度系统里，最终一致性主要用在三个地方：

场景	不一致窗口	收敛手段
Leader 选举	毫秒~秒级	租约机制 + 心跳检测
任务状态同步	秒级~分钟级	版本号 + 乐观锁
元数据变更	分钟级	事件驱动 + 补偿任务

3.2.1 租约机制：Leader 的「临时身份证」

调度系统通常用 Leader/Follower 架构。Leader 挂了怎么办？租约机制就是解决方案。

Leader 定期续约，续约失败就自动降级。其他节点发现租约过期，发起选举。这个过程中，系统处于「无 Leader」状态，但调度任务不会停——Follower 节点可以继续执行已经派发的任务。

避坑指南：我曾经把租约时间设得太短（200ms），结果网络抖动导致频繁选举，整个调度集群一直在「选主-降级-选主」的死循环里。后来改成 3 秒租约 + 1 秒心跳，稳了。

3.2.2 版本号 + 乐观锁：解决状态冲突

两个节点同时更新同一个任务状态怎么办？用版本号。

// 伪代码：乐观锁更新任务状态
function updateTaskStatus(taskId, newStatus, expectedVersion) {
    sql = "UPDATE tasks SET status = ?, version = version + 1 " +
          "WHERE task_id = ? AND version = ?";
    result = db.execute(sql, [newStatus, taskId, expectedVersion]);
    if (result.affectedRows == 0) {
        // 版本冲突，重试或丢弃
        handleConflict(taskId);
    }
}

这个模式简单有效。版本号冲突时，要么重试，要么丢弃——取决于业务语义。调度任务的状态变更，我建议「丢弃旧版本，保留新版本」，因为新版本通常代表更准确的状态。

3.2.3 补偿任务：兜底方案

最终一致性有个问题：如果一直收敛不了怎么办？补偿任务就是兜底方案。

举个例子：调度器派发任务后，Worker 节点执行完成，但状态回写失败了。调度器通过补偿任务定期扫描「执行中但超时」的任务，重新查询 Worker 状态，或者重新派发。

注意：补偿任务一定要有幂等性。同一个任务被补偿两次，不能产生两次副作用。我习惯在任务表里加一个 execution_id 字段，每次派发生成唯一 ID，Worker 端根据 ID 去重。

3.3 无状态化改造：让调度节点可以随便杀

调度系统的高可用，核心就是「节点可以随便挂，挂了不影响业务」。怎么做到？无状态化。

无状态不是说节点不存任何数据，而是「运行时状态不依赖本地存储」。所有状态都外移到中间件里。

3.3.1 状态外移：把「记忆」交给中间件

调度节点需要记住的东西不少：任务队列、执行进度、Leader 身份、Worker 心跳。这些东西如果存在本地内存里，节点一挂就丢了。

我的做法是：

任务队列 → Redis List 或 Kafka
执行进度 → 数据库（MySQL/PostgreSQL）
Leader 身份 → ZooKeeper / etcd
Worker 心跳 → Redis 带过期时间的 Key

这样一来，任何一个调度节点挂了，其他节点直接接管——数据都在中间件里，谁读都一样。

3.3.2 无状态化的代价：延迟增加

无状态化不是免费的。每次读写都走网络，延迟肯定比本地内存高。我见过一个团队把调度器的状态全部外移到 Redis，结果每次任务派发都要 3-5 次 Redis 操作，延迟从 1ms 涨到 10ms。

怎么优化？

批量操作：不要一次一个任务地写，攒一批再写。
本地缓存 + 异步同步：允许短暂不一致，先写本地，再异步同步到中间件。
连接池复用：别每次请求都建连接，复用连接池。

个人经验：我习惯在调度节点里加一层「本地状态缓存」，缓存时间不超过 1 秒。节点挂了最多丢 1 秒的状态，补偿任务能兜住。这样既保证了无状态化的弹性，又降低了延迟。

3.4 架构总览：CAP + 最终一致性 + 无状态化

把这三个原则串起来，调度系统的架构就清晰了。下面这张图展示了核心逻辑：

这张图把三个原则串起来了。从左到右：先选 AP，然后用最终一致性弥补 C 的缺失，最后通过无状态化让节点可以随便挂。三个原则缺一不可。

3.5 避坑总结

最后，把我这些年踩过的坑总结一下：

租约时间别太短：200ms 的租约在云环境下就是灾难。建议 3-5 秒。
补偿任务要有幂等：同一个任务补偿两次，不能产生两个结果。
无状态化不是零成本：延迟会增加，用本地缓存 + 异步同步来平衡。
版本号冲突别忽略：冲突了就要处理，不能静默失败。

我曾经犯过的错：有一次做调度系统升级，把状态从本地内存全部迁移到 Redis，结果忘了处理 Redis 连接中断的情况。Redis 挂了，整个调度集群直接瘫痪。后来加了本地缓存降级 + 自动重连，才算稳下来。

嗯，这一章的内容就这些。记住三个关键词：AP、最终一致、无状态。调度系统的高可用，就是在这三个原则下做权衡和取舍。