architecture-spec-writer

目标 构建一个高可用的分布式任务调度系统，支持秒级延迟的任务触发、动态扩缩容、任务依赖管理与失败重试机制。系统需保证任务至少执行一次，且在节点故障时自动恢复未完成任务。 非目标 - 不支持跨数据中心强一致性（允许最终一致） - 不提供图形化任务编排界面（仅提供API与CLI） - 不处理任务执行逻辑本身（仅负责调度与状态管理） 不变量 1. 每个任务在调度器中拥有唯一ID，且状态变更不可逆（pending → running → succeeded/failed/retrying）。 2. 任务执行结果必须持久化至存储层，即使调度器崩溃也能恢复状态。 3. 调度器实例间通过Leader选举机制确保同一时刻仅一个实例可分配任务。 接口 - **SubmitTask(task: TaskSpec) → TaskID** 提交任务，返回唯一ID。TaskSpec包含：cron表达式、执行命令、超时时间、重试策略、依赖任务ID列表。 - **GetTaskStatus(taskID: string) → TaskStatus** 返回任务当前状态及最近一次执行日志片段。 - **CancelTask(taskID: string) → bool** 取消处于pending或running状态的任务，返回是否成功。 - **ListTasks(filter: Filter) → []TaskSummary** 按状态、标签、时间范围过滤任务列表。 数据流 1. 用户通过API提交任务 → 写入任务元数据至PostgreSQL（主表tasks + 依赖表task_dependencies）。 2. Leader调度器周期性扫描tasks表中status=pending且满足触发条件的任务。 3. 对无依赖或依赖已完成的任务，生成执行实例写入execution_queue（Redis Stream）。 4. Worker从execution_queue消费任务，执行后更新tasks表状态，并触发下游依赖任务检查。 5. 失败任务根据retry_policy重新入队，最多重试3次后标记为failed。 依赖 - PostgreSQL：持久化任务元数据与状态（使用行级锁避免并发更新冲突） - Redis：作为任务执行队列（Stream结构）与分布式锁（Redlock算法实现Leader选举） - Prometheus + Grafana：监控任务延迟、队列积压、失败率等指标 - Kubernetes：部署调度器与Worker（HPA基于CPU/内存及自定义指标扩缩容） 失败模式 | 组件 | 故障场景 | 应对措施 | |------|--------|--------| | PostgreSQL | 主库宕机 | 切换至备库，任务提交短暂不可用（<30s） | | Redis | Stream数据丢失 | 依赖PostgreSQL重建队列（通过tasks表中status=running的任务重新入队） | | Worker | 执行中崩溃 | 任务超时后由调度器重新分配（timeout=300s） | | Leader调度器 | 选举失败 | 备用实例30秒内接管，未分配任务保留在DB中 | 上线计划 1. **Phase 1（影子模式）**：新系统并行运行，不处理真实任务，验证数据流与监控指标。 2. **Phase 2（灰度）**：10%生产任务路由至新系统，对比旧系统执行结果一致性。 3. **Phase 3（全量）**：关闭旧调度器，所有任务由新系统处理，保留旧系统7天回滚能力。 可观测性 - **指标**：task_submit_latency_ms、queue_backlog_count、task_failure_rate、worker_utilization - **日志**：结构化日志（JSON格式），包含task_id、stage（submit/schedule/execute）、error_code - **追踪**：OpenTelemetry集成，追踪任务从提交到完成的完整链路 验证计划 1. **正确性**：注入1000个带依赖关系的任务，验证执行顺序符合DAG拓扑排序。 2. **容错性**：随机杀死Worker/Leader实例，确认任务无丢失且自动恢复。 3. **性能**：压测至10K任务/秒提交，P99调度延迟<500ms，队列积压<1000。 开放问题 - 是否需要支持任务...

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本

相关资产