feat: stabilize multi-region runtime sync and worker orchestration

This commit is contained in:
root
2026-04-27 15:48:12 +08:00
parent 7cbde2aa78
commit 215a364891
137 changed files with 31931 additions and 1943 deletions

View File

@@ -0,0 +1,180 @@
# 当前已验证有效的线上参数与改动清单
> 说明:这份文档保留作阶段留档。后续执行和观察,统一以 [当前线上最终Runbook.md](/www/wwwroot/getDomain/docs/当前线上最终Runbook.md) 为准。
最后更新2026-04-25 17:30 左右
适用节点:`mainland-controller-01`
目标:给后续观察和继续优化留一个“当前已经验证有效”的固定基线,不再靠聊天记录回忆。
## 1. 当前线上基底
- 当前 `current` 指向:
`/opt/domaincheck/releases/domaincheck_release_20260424_220158`
- 当前核心服务状态:
- `domaincheck-worker.service = active`
- `domaincheck-sync-agent.service = active`
- `domaincheck-api.service = active`
说明:
- 这台机器现在不是只跑旧 release 原样代码,而是“`220158` 基底 + 多轮热补”。
- 后续如果要正式固化,应该把当前热补内容重新打一版正式 release。
## 2. 当前已确认生效的远端环境参数
以下参数已经在运行中的 `detect_worker.py` 进程环境里确认过,不是只改了文件没重启:
### 单机性能/爱站相关
- `DOMAINCHECK_REGISTER_SINGLE_MACHINE_MODE=1`
- `DOMAINCHECK_SINGLE_MACHINE_AIZHAN_DIRECT_FIRST=1`
- `DOMAINCHECK_AIZHAN_REMOTE_DISCONNECT_DEGRADE=1`
- `DOMAINCHECK_AIZHAN_EXTERNAL_FAST_DEGRADE=1`
- `DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_AIZHAN=2`
- `DOMAINCHECK_PROXY_STEP_MAX_SECONDS_AIZHAN=10`
- `DOMAINCHECK_AIZHAN_TIMEOUT_PROXY=1.8`
- `DOMAINCHECK_AIZHAN_TIMEOUT_DIRECT=2.4`
### Wayback 相关
- `DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_WAYBACK=2`
- `DOMAINCHECK_PROXY_STEP_MAX_SECONDS_WAYBACK=8`
- `WAYBACK_CDX_TIMEOUT=3`
- `WAYBACK_SNAPSHOT_TIMEOUT=2`
- `WAYBACK_RETRY_COUNT=1`
- `WAYBACK_DOMAIN_CONCURRENCY=1`
- `WAYBACK_MAX_RECORDS=2`
- `WAYBACK_TRANSIENT_BACKOFF_SECONDS=0.5`
## 3. 当前已确认上线的代码改动方向
这些不是“计划中”,而是已经热补到 `mainland-controller-01` 并跑起来的:
### 调度/分发侧
- 预补货提前触发,不再等批次快空了才补。
- 预补货时不让拿到锁的那个 worker 先独吞下一批任务。
- `pipeline` 推进和主动 `pull_tasks` 做了共享锁,减少 60 个 worker 同时拆批次。
- `session_replaced -> queued_before_start` 这条重复唤起链已经加护栏压住。
- `claim / finalize / release` 这些本地 DB 重链做过多轮减重,分钟级长尾已经明显掉下来。
### 注册/站点检测侧
- 注册检测保留单机性能模式。
- 百度、360、爱站都已经不再停留在过于激进的超时口径。
- `爱站` 已经补到:
- 单机模式下首轮可直连优先
- `RemoteDisconnected` 可直接降级
- 现在又进一步支持“外部依赖异常快速降级”,不再把整轮预算白白耗完
### Wayback 侧
- `wayback` 已经从“自己 backoff 把自己打死”收住。
- 当前远端新版逻辑里:
- `latest_cdx` transient 时,不再硬打额外的 `records_cdx`
- backoff 已收短到 `0.5s`
- 当前剩下主要是 `web.archive.org` 本身慢/拒绝连接
## 4. 这轮真正验证出来的效果
下面这些是已经实测到的,不是预估:
### 4.1 机器确实吃起来了
较早一轮稳定快照里,`mainland-controller-01` 已经出现:
- `60` 个节点全在线
- `53` 个子 worker 的 `active_threads > 0`
- `active_thread_count = 13531`
后续观察里,最近 2 分钟也长期能看到:
- `59` 个 fresh worker
- 大约 `51 ~ 56` 个 worker 有真实线程数大于 `0`
- 真实线程总和大约在 `3.8 万 ~ 4.2 万`
这说明当前不是“进程活着但没吃活”,而是确实在跑。
### 4.2 内存高位问题先被压下来了
滚动重启并替换旧 RSS 后,现场有过一轮明显回落:
- `Mem used ≈ 31Gi`
- `available ≈ 93Gi`
- `60` 个 worker 总 RSS 约 `23.9Gi`
说明“旧 RSS 不退”这层已经不是最早那种危险状态。
### 4.3 爱站与 Wayback 的尾部外部链,已经从“卡住不产出”变成“持续产出”
观察窗:`2026-04-25 17:17:18``17:29:23`
- `completed_total: 50786 -> 51298`,净增 `512`
- `aizhan_completed: 7718 -> 7936`,净增 `218`
- `wayback_completed: 3068 -> 3362`,净增 `294`
- 这段窗口里:
- `aizhan_failed = 0`
- `wayback_failed = 0`
这个结论很重要:
- 现在已经不是“压住 failed但 completed 不动”
- 而是“failed 压住了,同时 completed 也在持续增长”
### 4.4 爱站快速降级这刀确实有作用
更早一段观察里,`爱站 failed` 还是会堆。
在把 `DOMAINCHECK_AIZHAN_EXTERNAL_FAST_DEGRADE=1` 灰到远端后,后面的观察窗里:
- `aizhan_failed` 被压到 `0`
- `aizhan_completed` 持续增长
这说明当前主链里,对爱站这类外部依赖异常,“快速降级继续”是有效的。
## 5. 当前怎么理解这些数字
当前最应该盯的不是:
- 单次 `claimed`
- 单次 `pending`
- 某一个瞬间的 `running`
因为这是 `domain_pipeline`,前一步跑完会继续生成下一步,数字天然会波动。
当前更应该盯的是:
1. `completed_total` 是否持续增长
2. `aizhan_completed / wayback_completed` 是否持续增长
3. `aizhan_failed / wayback_failed` 是否继续维持低位
如果这三组数继续保持当前趋势,就说明这套配置是对的。
## 6. 当前不要再乱动的东西
在下一轮更长观察结束前,建议先不要再继续频繁改:
- worker 进程数
- 每进程线程上限
- claim / backlog 批量参数
- wayback / 爱站超时参数
原因很简单:
现在已经进入“参数开始生效、completed 在涨”的阶段,再频繁动,会把已验证有效的窗口打碎。
## 7. 下一步建议
当前建议先停手观察,不再继续大改参数。
优先做两件事:
1. 继续观察更长窗口
建议至少再看 `30 ~ 60` 分钟,确认:
- `completed_total` 继续增长
- `aizhan_completed / wayback_completed` 继续增长
- `aizhan_failed / wayback_failed` 不重新抬头
2. 之后再做正式固化
把当前这些热补过的代码和远端有效参数,整理进正式 release避免后续机器重启或重新发版时丢失。
## 8. 当前一句话结论
**这轮已经验证到:当前 `mainland-controller-01` 上这套“单机性能模式 + 外部依赖快速降级继续”的组合是有效的,主链已经从“线程忙但不出结果”切到“线程忙,同时持续产出 completed”。**