288 lines
11 KiB
Markdown
288 lines
11 KiB
Markdown
# 主线任务验收总表
|
||
|
||
更新时间：2026-04-21
|
||
|
||
## 当前执行原则
|
||
|
||
当前先只做一件事：
|
||
|
||
- 跑通主任务流程
|
||
- 把 7 个大任务按“可测试、可验收”的标准推进
|
||
- 并发、代理、展示层、CPU 打满这类细节优化先封存，不再抢主线
|
||
|
||
当前不再把“性能抠点”当主目标。
|
||
后续额度恢复后，再继续做细节优化专项。
|
||
|
||
## 当前主线优先级
|
||
|
||
按下面顺序推进，不跳步：
|
||
|
||
1. 大任务 1 真实验收闭环
|
||
2. 大任务 2 controller 编排闭环
|
||
3. 大任务 3 统一结果状态机闭环
|
||
4. 大任务 4 本地控制状态 + syncer/finalizer 闭环
|
||
5. 大任务 5 固定 worker pool + 持续补位替换旧模型
|
||
6. 大任务 6 时光机一期接入标准步骤
|
||
7. 大任务 7 运营视角指标面板落地
|
||
|
||
## 7 个大任务当前状态
|
||
|
||
### 大任务 1
|
||
单步骤任务底座落地
|
||
|
||
目标：
|
||
先打通 `controller -> queue -> claim -> worker -> result -> controller` 的完整闭环。
|
||
|
||
当前状态：
|
||
- 已有较完整代码底座
|
||
- `single_step` / `step_code` 模型已基本成形
|
||
- 现在缺的是“真实运行验收”而不是继续堆骨架
|
||
|
||
本任务验收只认下面 5 件事：
|
||
|
||
1. controller 能生成 `baidu_check` 任务
|
||
2. worker 能拉到 `baidu_check` 任务并执行
|
||
3. worker 能回传标准化结果
|
||
4. controller 能更新本地步骤状态
|
||
5. worker 超时未回传时，任务会回收重投
|
||
|
||
当前结论：
|
||
- 代码方向已基本对齐
|
||
- 2026-04-20 已完成一轮 live 验收打钩：
|
||
- `controller` 已生成 `single_step / detect_baidu_site` 任务（例：`job_id=6`, `job_code=step-20260420153527-9fc7b5`）
|
||
- `worker` 已精准领取当前 `job_id` 并执行，不再被旧 `pipeline / sync / legacy fallback` 污染
|
||
- `worker` 已回传标准化结果到 `detect_job_items.result_payload_json`
|
||
- `controller` 已可按 `job_id` 定向执行 `process_pipeline`，并把结果落到本地 `domain_detections.baidu_site`
|
||
- “超时/遗留未回传”链路已验证会被节点启动释放并重新领取执行（`job_id=5` 在遗留 `running` 后被重新释放、重新领取并完成）
|
||
- 当前主线结论：大任务 1 已达到“可验收通过”状态，可以继续把主精力切到大任务 2 / 3
|
||
|
||
### 大任务 2
|
||
pipeline 编排器落地
|
||
|
||
目标：
|
||
把“下一步跑什么”彻底收回 controller。
|
||
|
||
当前状态：
|
||
- 基础方向已落到 controller 驱动
|
||
- 还需要继续做“按后台勾选顺序推进 / 按域名属性跳过”的真实验收
|
||
|
||
本任务必须确认：
|
||
- 同一个域名不会在 worker 里串完整条链
|
||
- controller 是唯一推进者
|
||
- 勾选顺序变化能影响下一步投递
|
||
- 跳过规则生效
|
||
|
||
当前结论：
|
||
- 已进入可验收阶段
|
||
- 2026-04-20 已补上关键收口：
|
||
- `single_step` 会话下，worker 只按当前 `job_id` 领取任务
|
||
- `single_step` 会话下，旧的 `pipeline 推进 / sync pull / legacy fallback` 已被显式跳过
|
||
- `process_pipeline` 已支持按 `job_id` 定向处理，方便 controller 精准推进当前步骤
|
||
- 2026-04-20 又补完一轮 live 验收：
|
||
- `pass`：`detect_baidu_site` 完成后，controller 已为同一 `job` 创建下一步 `detect_360_site`
|
||
- `skip`：一口价域名在 `detect_register + detect_baidu_site` 配置下，会直接解析到 `detect_baidu_site`
|
||
- 同时修掉了一个真实阻塞点：`process_pipeline()` 事务内再开第二连接写 `detect_run_events` 会把 controller 自己锁住；现已改成同事务同 cursor 写事件
|
||
- 当前主线结论：大任务 2 的 controller 编排主干已可验收，剩下更多是扩步骤和补更细跳过规则
|
||
|
||
### 大任务 3
|
||
步骤结果判定与重试策略落地
|
||
|
||
目标：
|
||
统一 `pass / retry / black_hit / reject`。
|
||
|
||
当前状态：
|
||
- 结果结构、重试入口、黑名单终止方向已基本进入主链
|
||
- 还需要补 live 验收，重点是 TTL 回收、重投、终止规则
|
||
|
||
本任务必须确认：
|
||
- 外部失败会重投当前步骤
|
||
- 黑名单命中会终止后续步骤
|
||
- 非黑名单业务不通过按规则终止
|
||
- 不会出现同一步无限重试
|
||
|
||
当前结论：
|
||
- 代码已明显推进
|
||
- 2026-04-20 已完成 controller 侧 live 验收：
|
||
- `retry`：`state=degraded` 会重投当前步骤，不推进下一步
|
||
- `black_hit`：`state=blacklisted` 会终止后续步骤并结束当前 job
|
||
- `reject`：`state=rejected` 会终止当前流程，不再重试
|
||
- worker 侧也已补上业务失败 -> `rejected` 的结果态，不再把业务不通过和技术失败都混成 `failed`
|
||
- 当前主线结论：大任务 3 的统一结果状态机已基本闭环，可继续往大任务 4 / 5 推进
|
||
|
||
### 大任务 4
|
||
本地控制状态与海外主库同步落地
|
||
|
||
目标：
|
||
controller 本地维护高频状态，syncer 批量同步海外主库，finalizer 标记流程完成。
|
||
|
||
当前状态：
|
||
- 本地状态和部分同步链路已经在跑
|
||
- 已补上“最近完成任务快照也继续产出结果投影”
|
||
- 已补上结果导入后按 job_code 优先定位本地 job，并刷新本地 job 收尾状态
|
||
- syncer/finalizer 还缺少一轮 live 闭环验收
|
||
|
||
本任务必须确认：
|
||
- 高频链路不依赖 worker 频繁直写海外主库
|
||
- controller 本地状态完整
|
||
- 批量同步成功
|
||
- 流程完成状态准确
|
||
|
||
当前结论：
|
||
- 代码主链已进一步收口
|
||
- 2026-04-21 已确认 `detect_result_projection / runtime_projection` 在 `detect_sync_records` 中持续产出且状态为 `projected`
|
||
- 当前说明 syncer 主链已恢复，但“本地 job 收尾状态 + 主库最终账本完全一致”的终验还需要继续盯现场
|
||
|
||
### 大任务 5
|
||
worker 池化与持续补位调度落地
|
||
|
||
目标：
|
||
真正替掉“批量认领 + 批量等待”的旧模型。
|
||
|
||
当前状态：
|
||
- 已经做了多轮并发热路径优化
|
||
- 已进一步压缩 executor 内部 backlog，补位更接近固定槽位模型
|
||
- 但还需要一轮 live 运行观察 claimed/running 曲线，确认旧的批量认领惯性已被压住
|
||
|
||
本任务必须确认：
|
||
- 活跃槽位稳定贴近配置上限
|
||
- 并发不再大起大落
|
||
- 吞吐明显提升
|
||
- 调度器自耗下降
|
||
|
||
当前结论：
|
||
- 这是主线里仍然偏重的未完项
|
||
- 2026-04-21 已继续做现场修正：
|
||
- `claim_detect_job_items()` 已显式排除空 `step_code` 的 legacy 项，避免 worker 从标准队列入口继续误吞旧 whole-domain 项
|
||
- `mainland-controller-01 / 121.204.244.188` 与 `mainland-worker-01 / 121.204.244.248` 均已确认在真大陆节点参与执行
|
||
- 海外控制面 `queue_health / dashboard` 已补上“读取大陆 runtime/debug 近窗执行流”的兜底口径
|
||
- 当前首页已能看到真实近窗吞吐，例如 `10-15 项/分钟` 量级、并能拆到 controller/worker 两个节点
|
||
- 当前主线判断：
|
||
- “高 claimed 假活跃”问题已继续缓解
|
||
- “活吞吐不可见”问题已明显改善
|
||
- 但“总 completed 账本持续增长”和“running 贴近线程上限”仍未彻底验收，所以大任务 5 仍未签字通过
|
||
|
||
### 大任务 6
|
||
时光机一期流程落地
|
||
|
||
目标：
|
||
时光机按“最近 5 年”方案接成标准步骤任务。
|
||
|
||
当前状态：
|
||
- 现有项目里已有时光机相关检测逻辑
|
||
- 但还没有完全按标准步骤任务方式接进新 pipeline 验收
|
||
|
||
本任务必须确认：
|
||
- wayback 作为标准步骤任务接入
|
||
- 最近 5 年快照策略稳定
|
||
- 返回标准化结果
|
||
- controller 能把它当普通步骤推进/终止
|
||
|
||
当前结论：
|
||
- 2026-04-21 已落代码并通过测试：
|
||
- `detect_wayback` 已作为标准 `single_step` 步骤接入 controller / worker 主链
|
||
- 时光机一期已按“最近 5 年 + 命中即停”策略落地到 payload 和 detector
|
||
- 焦点测试已通过
|
||
- 但还缺 live 现场验收：
|
||
- 真实任务投递
|
||
- worker 执行
|
||
- 标准化结果回传
|
||
- controller 按普通步骤推进/终止
|
||
- 当前主线结论：大任务 6 已进入“代码落地完成、待现场验收”状态
|
||
|
||
### 大任务 7
|
||
运营视角指标与验收面板落地
|
||
|
||
目标：
|
||
让后台能判断“有没有跑起来、卡在哪一步、多久跑完”。
|
||
|
||
当前状态：
|
||
- 后端已有部分 runtime / detect status / debug event 统计基础
|
||
- 但完整的运营视角指标面板还没有完全落地验收
|
||
|
||
本任务必须确认：
|
||
- 每步骤队列数
|
||
- 每步骤吞吐
|
||
- 每分钟完成量
|
||
- 当前 pipeline 分布
|
||
- 重试数 / 黑名单数 / 失败数
|
||
- 预估剩余时间
|
||
|
||
当前结论：
|
||
- 2026-04-21 已落地首页最小运营面板，并补了第二层口径修正：
|
||
- `completed / pending / running` 已切到“全活跃任务累计口径”
|
||
- `步骤队列 / 节点吞吐 / 重试压力 / 有效执行节点` 已可直接展示
|
||
- `ETA` 在无真实近窗完成量时会显示“待计算”，避免误报 0 小时
|
||
- 2026-04-21 又补上“大陆 runtime/debug 近窗执行流”兜底：
|
||
- `active_job` 已可显示 `runtime_job_code`
|
||
- `processed_per_minute / completed_recent / node_throughput / step_queue` 已能贴近大陆真实执行
|
||
- 首页已能直接区分 `db_job_code` 与 `runtime_job_code`
|
||
- 当前结论：大任务 7 已进入“可运营分析并能指导现场排障”阶段，但仍需继续把“总 completed 账本”和“最终验收面板”完全统一
|
||
|
||
## 现在只做什么
|
||
|
||
当前只盯主线，不跑偏：
|
||
|
||
1. 把大任务 1 做成可真实验收
|
||
2. 验收过后立刻推进大任务 2
|
||
3. 再按顺序推进 3、4、5、6、7
|
||
|
||
如果某个问题只是：
|
||
|
||
- CPU 没吃满
|
||
- 某个 timeout 还能再抠
|
||
- 代理池还能更激进
|
||
- 页面还能再改得更好看
|
||
|
||
都先不打断主线。
|
||
|
||
## 已封存的细节优化 backlog
|
||
|
||
下面这些不是不做，而是先封存：
|
||
|
||
### A. 并发/调度优化
|
||
|
||
- 固定 worker pool 彻底替换旧批量认领模型
|
||
- claimed 回弹继续压缩
|
||
- executor 内部排队继续收紧
|
||
- 活跃 running 继续往上抬
|
||
- controller / worker 双节点吞吐平衡
|
||
|
||
### B. DB 往返优化
|
||
|
||
- 继续合并 `domains` 表高频更新
|
||
- 继续减少 `mark_running / finalize` 这类必要写库点开销
|
||
- 能走 Redis 或本地状态的尽量不走高频 DB
|
||
|
||
### C. 外部请求链路优化
|
||
|
||
- 代理失败后的重试链继续压缩
|
||
- 直连失败后回代理的等待窗口再收紧
|
||
- 无代理窗口等待策略再优化
|
||
- 外部请求 timeout 再按真实成功率调优
|
||
|
||
### D. 代理池策略优化
|
||
|
||
- 代理池刷新频率与补位策略继续增强
|
||
- 失败代理淘汰与新代理拉取节奏继续优化
|
||
- 控制“不过度预验证”和“不过度浪费线程”之间的平衡
|
||
|
||
### E. 运营展示层优化
|
||
|
||
- 更细的 runtime 面板
|
||
- ETA / 每分钟吞吐更精细展示
|
||
- 日志窗口布局继续优化
|
||
- 非主线的页面交互增强
|
||
|
||
## 接下来执行口径
|
||
|
||
接下来统一按这个口径推进：
|
||
|
||
- 先验收主流程
|
||
- 再补主流程缺口
|
||
- 性能细节先记账，不抢主线
|
||
- 每做完一个大任务，就给出“是否验收通过”的明确结论
|
||
|
||
一句话定调：
|
||
|
||
当前阶段不是“继续无限抠并发”，而是“先把 7 个大任务按主线流程逐个打通并验收”。
|