254 lines
7.0 KiB
Markdown
254 lines
7.0 KiB
Markdown
# IMPLEMENTATION_STATUS
|
||
|
||
更新时间：2026-04-19 03:41 CST
|
||
|
||
## 当前真实状态
|
||
|
||
阶段判断：
|
||
|
||
- 海外单脑接管能力：约 `95%`
|
||
- 分布式检测真实执行能力：约 `88%~90%`
|
||
- 距离“可稳定上线并放心用后台发起检测”：约 `86%~89%`
|
||
|
||
## 本轮最新结论
|
||
|
||
这轮结论需要更新为四段：
|
||
|
||
- 接管与同步能力已经明显趋于完成
|
||
- worker 控制消息补偿链已经完成线上验证
|
||
- controller 运行环境漂移已经被现场修正
|
||
- 当前唯一剩余主阻塞已经收紧到 controller 代理池无可用代理
|
||
|
||
## 当前证据拆分
|
||
|
||
### 1. 代码闭环
|
||
|
||
已经完成：
|
||
|
||
- `detect_result_projection` 支持 `recent_domain_events`
|
||
- 中央 ingest 会把逐条事件写入 `detect_run_events`
|
||
- `sync_agent` 会自动产出 `detect_result_projection`
|
||
- worker 控制消息新增 `request_id`
|
||
- worker 运行态心跳会补偿消费 pending 控制消息
|
||
- worker 收到并处理控制消息后会按 `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`
|
||
- 启动后发现待执行控制指令
|
||
- 接受 `start_detection`
|
||
- 开始执行远程检测任务
|
||
- `mainland-controller-01`
|
||
- 修正 Redis 环境后
|
||
- 重新接受 `start_detection`
|
||
- 开始执行远程检测任务
|
||
|
||
### 2. 接管/同步闭环
|
||
|
||
当前已完成：
|
||
|
||
- `remote_access_ready = 3/3`
|
||
- `log_sync_state = full_capture`
|
||
- `mainland-controller-01` 的 `domaincheck-sync-agent` 已重启到新进程
|
||
- 首轮 `detect_result_projection` 推送成功过一次
|
||
- 中央已收到 mainland 首批 `domain_*` 事件
|
||
|
||
这说明：
|
||
|
||
- mainland 到中央的基础同步链是活的
|
||
- 结果投影链至少成功打通过一次
|
||
|
||
### 3. 检测执行闭环
|
||
|
||
当前未完成：
|
||
|
||
- 短观察窗口内：
|
||
- `progress_percent` 仍是 `2.1`
|
||
- `items_completed` 仍是 `21`
|
||
- `items_claimed` 仍是 `34`
|
||
- `items_pending` 仍是 `931`
|
||
- 中央 recent events 已刷新到更晚时间
|
||
- `runtime/sync-summary` 最新记录已继续增长
|
||
- 但 completed 尚未继续上涨
|
||
|
||
这说明：
|
||
|
||
- 当前不是单纯“页面没刷新”
|
||
- 而是执行现场这段时间没有继续出结果
|
||
|
||
## 本轮新增硬证据
|
||
|
||
通过中央观测面、节点现场日志和远端 `domaincheck-worker` 日志，已确认：
|
||
|
||
- `mainland-controller-01` 现场日志显示：
|
||
- `当前可用代理数: 0`
|
||
- `最近结果: 刷新成功，可用 0 个`
|
||
- controller 新增远端日志显示：
|
||
- 代理源拉取成功
|
||
- 抽样校验后 `共 0 个可用代理`
|
||
- 失败集中在：
|
||
- `ProxyError@https://m.baidu.com`
|
||
- `Unable to connect to proxy`
|
||
- `ConnectTimeoutError`
|
||
- worker 新增远端日志显示：
|
||
- `发现待执行 Worker 控制指令`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
- 说明线上补偿消费链已真正工作
|
||
- controller 新增远端日志显示：
|
||
- 初次重启后：
|
||
- `Authentication required`
|
||
- `maximum recursion depth exceeded`
|
||
- 进一步排查确认：
|
||
- `/etc/default/domaincheck-worker` 的 `REDIS_PASSWORD` 为空
|
||
- 修正后再次重启：
|
||
- `Redis 连接成功: 127.0.0.1:6379`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
- 后续日志继续收紧到：
|
||
- `代理已启用，但当前无可用代理`
|
||
- 两台大陆节点 full capture 已开启，但源日志时间没有继续前进
|
||
|
||
这说明：
|
||
|
||
- worker 控制消息链不再是主阻塞
|
||
- controller Redis 环境漂移也不再是主阻塞
|
||
- 当前第一主阻塞已经进一步收紧到 controller 代理池不可用
|
||
- worker 的时光机异常是客观存在的次级问题
|
||
- 不是控制面未接管
|
||
- 不是同步链未打通
|
||
|
||
## 本轮新增代码修复
|
||
|
||
本轮不是只停留在诊断，还补了一处运行态最小修复：
|
||
|
||
### 修复点 1：控制消息唯一标识
|
||
|
||
- 文件：
|
||
- `domain-api/app/services/worker_control_service.py`
|
||
- 变更：
|
||
- 每次 `send_worker_command(...)` 都附带 `request_id`
|
||
- Redis `publish` 与 pending fallback 使用同一份消息体
|
||
|
||
### 修复点 2：worker 运行态补偿消费 pending 指令
|
||
|
||
- 文件：
|
||
- `domainCheck/detect_worker.py`
|
||
- 变更：
|
||
- 心跳线程每轮会补偿尝试消费 pending 控制消息
|
||
- 解决“worker 在线但 pubsub 消息漏收，导致 pending 指令长期不被消费”的风险
|
||
|
||
### 修复点 3：worker 收到指令后确认清理 pending
|
||
|
||
- 文件：
|
||
- `domainCheck/detect_worker.py`
|
||
- 变更：
|
||
- worker 实际收到控制消息后，会按 `request_id` 清理对应 pending 指令
|
||
- 避免修复后又产生重复回放
|
||
|
||
### 当前判断
|
||
|
||
这组修复解决的是：
|
||
|
||
- “检测启动已经发布，但 worker 可能静默漏收”的代码风险
|
||
|
||
所以当前最准确的状态是：
|
||
|
||
- 代码级控制链缺口已补上
|
||
- 线上部署验证已通过
|
||
- 但 `controller` 代理池校验后 `0 available` 的现场阻塞仍然存在
|
||
|
||
## 当前已闭合的问题
|
||
|
||
已闭合：
|
||
|
||
- 大陆 controller 无法 `pull_tasks`
|
||
- Detect 页面误判“大陆没跑”
|
||
- Detect 主统计口径不一致
|
||
- Runtime / Queue / Detect 主摘要不统一
|
||
- 中央逐条事件接收缺口
|
||
- `sync_agent` 自动产出结果投影缺口
|
||
|
||
## 当前唯一剩余问题
|
||
|
||
当前唯一主问题仍然是：
|
||
|
||
- 检测执行面没有恢复到持续产出
|
||
|
||
但现在已经不需要再拆成“代码待验证”和“现场阻塞”两层。
|
||
|
||
当前唯一剩余现场阻塞就是：
|
||
|
||
- controller 代理池可用性为 0
|
||
- 因此没有持续产生新的 domain 级结果
|
||
|
||
换句话说：
|
||
|
||
- 现在不是逻辑未实现
|
||
- 不是中央映射失败
|
||
- 不是节点未接管
|
||
- 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败
|
||
|
||
## acceptance 当前状态
|
||
|
||
最新接管验收结果仍然成立：
|
||
|
||
- `pbr-9ce5c85f17`：`onboarding.acceptance` 成功
|
||
- `pbr-389abd618c`：`onboarding.acceptance` 成功
|
||
|
||
旧的 `attention` run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。
|
||
|
||
## 当前是否可以继续跑检测测试
|
||
|
||
当前结论：
|
||
|
||
- 可以继续做最小运行态排查
|
||
- 但不需要再优先验证 worker 控制消息链
|
||
- 当前还不能把状态视作“后台检测已经稳定恢复”
|
||
|
||
## 当前是否建议直接上线
|
||
|
||
当前结论：
|
||
|
||
- 不建议现在按“可稳定上线”判断
|
||
|
||
原因不是接管面，而是执行面：
|
||
|
||
- 三台节点都已接入
|
||
- worker / controller 都已重新接上控制链
|
||
- 但当前任务没有持续吞吐
|
||
- controller 代理池全部验不过会直接影响检测产出
|
||
|
||
## 当前优先级判断
|
||
|
||
最高优先级：
|
||
|
||
- `J2-检测执行停滞收口批`
|
||
|
||
当前不应继续推进：
|
||
|
||
- 新控制面功能
|
||
- 新模块
|
||
- 新页面
|
||
- 发布动作
|
||
- 与检测执行停滞无关的工作
|
||
|
||
## 完成下一轮后的预期
|
||
|
||
如果下一轮确认：
|
||
|
||
- controller 代理池恢复可用
|
||
- `domain_*` 开始继续增长
|
||
- `items_completed` 和近窗吞吐重新前进
|
||
|
||
则整体可上线程度预计可回升到：
|
||
|
||
- `92%~94%`
|
||
|
||
在那之前，当前口径应保持保守。
|