getDomain/docs/base.md

主线任务验收总表

更新时间：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 个大任务按主线流程逐个打通并验收”。