286 lines
8.0 KiB
Markdown
286 lines
8.0 KiB
Markdown
# TASK_BOARD
|
||
|
||
更新时间：2026-04-19 03:41 CST
|
||
|
||
## 当前主批次
|
||
|
||
唯一主批次：`J2-检测执行停滞收口批`
|
||
|
||
目标：
|
||
|
||
- 不进入新页面
|
||
- 不扩展控制面
|
||
- 不新增发布动作
|
||
- 只收口当前唯一真实阻塞：
|
||
- 节点已接管
|
||
- 同步已打通
|
||
- 但检测执行没有继续产出新结果
|
||
|
||
## 本轮最新状态
|
||
|
||
本轮已经完成“代码修复 -> 两台大陆节点部署 -> 运行态复查”的完整一轮验证。
|
||
|
||
### 已完成的最小修复
|
||
|
||
- `worker_control_service.send_worker_command(...)`
|
||
- 为每条 worker 控制消息补上 `request_id`
|
||
- 保证 Redis 发布与 pending fallback 使用同一份负载
|
||
- `detect_worker`
|
||
- 在运行态心跳里周期性补偿消费 pending 控制消息
|
||
- 在真正收到控制消息后，按 `request_id` 清理 pending 指令
|
||
|
||
本地验证已通过：
|
||
|
||
- `unittest domain-api/tests/test_worker_control_service.py`
|
||
- `python -m py_compile domainCheck/detect_worker.py domain-api/app/services/worker_control_service.py`
|
||
|
||
### 已完成的线上验证
|
||
|
||
- `mainland-worker-01`
|
||
- 已拉到 `main` 最新提交 `c33f4f1`
|
||
- 已重启 `domaincheck-worker`
|
||
- 启动后明确出现：
|
||
- `发现待执行 Worker 控制指令`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
- `mainland-controller-01`
|
||
- 已拉到 `main` 最新提交 `c33f4f1`
|
||
- 已重启 `domaincheck-worker`
|
||
- 发现运行环境漂移：
|
||
- `/etc/default/domaincheck-worker` 中 `REDIS_PASSWORD` 为空
|
||
- 已最小修正该节点运行环境后再次重启
|
||
- 修正后明确出现：
|
||
- `Redis 连接成功: 127.0.0.1:6379`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
|
||
### 本轮仍未完成的事情
|
||
|
||
- 中央 `items_completed` 仍未在短观察窗口内继续增长
|
||
- `mainland-controller-01` 仍然持续报：
|
||
- `代理已启用，但当前无可用代理`
|
||
- 因此当前剩余阻塞已经进一步收紧到：
|
||
- controller 现场代理池没有可用代理
|
||
|
||
## 本轮最新复查结果
|
||
|
||
本轮在完成修复部署后，中央与节点现场出现了新的运行证据：
|
||
|
||
- 活跃任务仍是 `detect-20260417170546-96023e`
|
||
- `mainland-worker-01` 最新事件时间已经从旧窗口推进到：
|
||
- `2026-04-19 16:37:00`
|
||
- `runtime/sync-summary` 最新记录已继续增长到：
|
||
- `id = 5491`
|
||
- `created_at = 2026-04-19 03:40:45`
|
||
- 说明中央已经重新收到新的运行侧同步流量
|
||
- 但短窗口内主进度仍未松动：
|
||
- `completed = 21`
|
||
- `running = 14`
|
||
- `claimed = 34`
|
||
- `pending = 931`
|
||
- controller 现场最新日志已收紧为：
|
||
- `代理已启用，但当前无可用代理`
|
||
|
||
## 关键证据
|
||
|
||
### 证据 1：接管与同步已通
|
||
|
||
当前中央状态：
|
||
|
||
- `remote_access_ready = 3/3`
|
||
- `log_sync_state = full_capture`
|
||
- mainland controller 的 `domaincheck-sync-agent` 已在新进程上运行
|
||
|
||
说明：
|
||
|
||
- 当前不是接管问题
|
||
- 也不是日志回传问题
|
||
- 更不是同步链完全断开
|
||
|
||
### 证据 2：检测任务当前没有继续出新结果
|
||
|
||
连续 40 秒前后对比结果完全一致：
|
||
|
||
- `JOB_PROGRESS = 2.1`
|
||
- `items_completed = 21`
|
||
- `items_running = 14`
|
||
- `items_claimed = 34`
|
||
- `items_pending = 931`
|
||
|
||
说明：
|
||
|
||
- 当前不是“页面慢一拍”
|
||
- 而是执行面这段时间确实没有继续产出
|
||
|
||
### 证据 3：中央 mainland 逐条结果没有继续增长
|
||
|
||
当前中央查询结果：
|
||
|
||
- mainland `domain_started/domain_completed/domain_failed/domain_blacklisted`
|
||
- 仍为 `10`
|
||
- 最新 mainland `detect_result_ingest`
|
||
- 仍为 `5382`
|
||
|
||
说明：
|
||
|
||
- 首批同步成功过
|
||
- 但后续并没有继续流入新逐条结果
|
||
|
||
### 证据 4：controller 现场日志已指向代理池可用性为 0
|
||
|
||
`mainland-controller-01` 现场日志显示：
|
||
|
||
- `当前可用代理数: 0`
|
||
- `最近结果: 刷新成功，可用 0 个`
|
||
- 免费检测链包含：
|
||
- 注册查询
|
||
- 百度 site
|
||
- 360 site
|
||
- 站长之家
|
||
- 爱站
|
||
- 时光机
|
||
|
||
进一步的远端 `logs.collect(domaincheck-worker)` 结果显示：
|
||
|
||
- controller 能从 6 个代理源成功拉到原始代理
|
||
- 但在抽样验证后：
|
||
- `代理池刷新完成，共 0 个可用代理`
|
||
- 失败原因集中在：
|
||
- `ProxyError@https://m.baidu.com`
|
||
- `Unable to connect to proxy`
|
||
- `ConnectTimeoutError`
|
||
|
||
说明：
|
||
|
||
- 当前不是代理源接口没返回
|
||
- 而是“拿到的代理全部验不过”
|
||
- 主阻塞已经可以精确收紧到 controller 代理池不可用
|
||
|
||
### 证据 5：worker 的时光机异常存在，但不是第一主因
|
||
|
||
`mainland-worker-01` 的远端 `domaincheck-worker` 日志显示：
|
||
|
||
- 存在：
|
||
- `时光机检测 外部依赖异常，步骤降级继续执行`
|
||
- 同时仍可见：
|
||
- `域名检测完成`
|
||
- 最近收到控制消息后：
|
||
- `收到启动检测指令，但检测任务已在运行，忽略重复启动`
|
||
|
||
说明：
|
||
|
||
- worker 并不是完全不能执行
|
||
- 时光机异常是客观存在的次级问题
|
||
- 但它不像 controller 代理池为 0 那样直接卡住整体吞吐
|
||
|
||
### 证据 6：full_capture 已开启，但源日志时间没有继续前进
|
||
|
||
节点现场日志最新可见记录仍停在较早时间：
|
||
|
||
- `mainland-controller-01`
|
||
- 最近样本集中在 `01:00:23`
|
||
- `mainland-worker-01`
|
||
- 最近样本集中在 `01:00:35`
|
||
|
||
额外 35 秒观察窗口结果：
|
||
|
||
- `capture_at` 没有继续前进
|
||
- `source_msg` 里的源日志时间也没有继续前进
|
||
|
||
说明：
|
||
|
||
- 不是“全量日志没开”
|
||
- 也不是“日志回传没回来”
|
||
- 而是执行进程这段时间确实没有继续产生日志
|
||
|
||
### 证据 7：worker 控制消息补偿链已在线上验证生效
|
||
|
||
之前运行态存在一个真实风险：
|
||
|
||
- `runtime.start_detection` 成功只代表“控制消息已发布到 Redis”
|
||
- 如果 worker 在线但恰好漏收了 pubsub 消息
|
||
- pending 指令只在启动或重连时消费，就可能造成：
|
||
- 页面显示“已启动”
|
||
- 但 worker 实际没有进入新的执行流
|
||
|
||
当前已完成最小修复：
|
||
|
||
- 每条控制消息带 `request_id`
|
||
- worker 心跳会主动补偿消费 pending 指令
|
||
- worker 真正收到并处理后，会按 `request_id` 清理 pending
|
||
|
||
这一步现在已经不再是“待部署假设”，而是已被线上日志确认生效：
|
||
|
||
- `mainland-worker-01` 已从 pending 指令恢复执行
|
||
- `mainland-controller-01` 在修正 Redis 环境后，也已重新接受并执行 `start_detection`
|
||
|
||
## 当前结论
|
||
|
||
当前结论要收敛成一句话：
|
||
|
||
- 接管链路已基本完成
|
||
- 同步链路已至少成功贯通一次
|
||
- 当前主阻塞仍是检测执行面没有恢复到“持续产出”
|
||
- 但代码级控制链缺口已经闭合
|
||
- 当前唯一剩余现场阻塞可以收紧为：
|
||
- `mainland-controller-01` 代理池可用性为 `0`
|
||
- worker 侧时光机异常仍是次级噪音，不应继续放大
|
||
|
||
## 下一步唯一主批次
|
||
|
||
唯一主批次维持为：`J2-检测执行停滞收口批`
|
||
|
||
本批次唯一目标：
|
||
|
||
- 保持当前不扩功能
|
||
- 只围绕 controller 代理池可用性为 `0` 做收口
|
||
- 继续观察修正后的 controller 是否开始产出 domain 级结果
|
||
- 若仍无结果增长，则只给出代理层最小补救路径
|
||
|
||
## 候选批次
|
||
|
||
### Candidate J3
|
||
|
||
名称：检测执行恢复验证批
|
||
|
||
进入条件：
|
||
|
||
- `J2` 明确根因后
|
||
- 代理或外部站点依赖恢复
|
||
- 再观察 `domain_*` 是否重新增长
|
||
|
||
### Candidate J4
|
||
|
||
名称：上线签收证据批
|
||
|
||
进入条件：
|
||
|
||
- `J3` 确认检测重新持续产出
|
||
- `go-live-summary` 只剩历史 attention
|
||
|
||
## 暂停项
|
||
|
||
继续暂停：
|
||
|
||
- 新页面
|
||
- 新模块
|
||
- 控制面增强
|
||
- 发布动作
|
||
- 与检测执行停滞无关的工作
|
||
|
||
## 下一轮唯一动作
|
||
|
||
下一轮唯一应该继续做的事情：
|
||
|
||
- 只做 controller 代理收口：
|
||
- 继续复查 controller `domaincheck-worker` 日志
|
||
- 观察是否从 `当前无可用代理` 转为有可用代理
|
||
- 继续复查 `/api/v1/detect/job/active`
|
||
- 继续复查 `/api/v1/runtime/sync-summary`
|
||
- 继续复查 recent domain events 是否出现 controller / 新 completed
|
||
- 唯一判断问题是：
|
||
- controller 代理池恢复后，completed 是否开始继续增长
|
||
- 是否仍是 `近窗吞吐 0`
|
||
- 是否仍是 `controller 可用代理数 0`
|
||
- 代理恢复后 `domain_*` 是否重新增长
|