feat(all): 源精度命名体系、工作流可观测台、节点停用管理与白名单归档
核心变更：
1. GridAxisValue 源精度命名
- 新增 GridAxisValue 类型，携带 f64 数值 + YAML 源书写文本（Deref 透明兼容算术）
- config.rs 绕过 serde_yaml 归一化，逐 token 捕获轴值原文（logg: 5.0 → g5.0）
- runner/executor/scheduler 全链路改用 DB TEXT 列权威 point_name，
修复 REAL 列回读丢精度导致的 model_name 错配
2. 工作流执行可观测台
- 新增 stats/progress/points 三组 API（进度时间序列、经验速率 ETA、
停滞预警、逐点明细分页、收敛性热力图数据）
- 新增 workflow_progress_snapshots 表 + tasks/grid_points 耗时列
- runner 携带 last_iter/worst_depth/n_depths 进 conv.json
- 前端新增 hash 路由、工作流详情页（概览/网格点/收敛分析三 Tab）、YAML 编辑器
3. 节点停用/启用管理
- 新增 disabled 状态 + disable/enable API；停用节点保持心跳但停止分发，
worker 空闲待命而非退出；移除 revoke API，token 失效统一走重发覆盖；
移除 host_name 字段
4. 白名单结果归档
- 新增 result_filter 模块，只归档有语义产物，丢弃 Tlusty 中间单元（~2MB/模型）
- executor 原子写入归档 + 200 点 LRU 上限
5. 历史数据导入
- sync_seeds 重写为 import_results：经 /admin/import_seed 标记 converged +
按新版命名迁移产物树
6. 部署与目录重规划
- data/results→seeds、data/archive→result + migrate_data_dirs.sh
- deploy.sh 增强（SSH 复用、Profile、远程 env）；Dockerfile 瘦身
7. 文档同步更新 api/database/architecture/deployment
This commit is contained in:
+69
-11
@@ -15,7 +15,7 @@ flowchart TB
|
||||
DB[(主数据库 dcts.db)]
|
||||
MQ[(任务队列 dcts_queue.db)]
|
||||
Scheduler["Grid Scheduler 网格调度器"]
|
||||
SeedsStorage["本地种子库 results/*.7"]
|
||||
SeedsStorage["本地种子库 seeds/*.7"]
|
||||
|
||||
API <--> DB
|
||||
API <--> MQ
|
||||
@@ -33,8 +33,8 @@ flowchart TB
|
||||
Worker1 -- "2. 下载种子/基础数据" --> API
|
||||
Worker1 -- "3. 汇报结果/上传 .7 大气" --> API
|
||||
|
||||
Worker2 -- "HTTP REST / Bearer Auth" --> API
|
||||
WorkerN -- "HTTP REST / Bearer Auth" --> API
|
||||
Worker2 -- "免凭据注册申请 / 审批后心跳" --> API
|
||||
WorkerN -- "免凭据注册申请 / 审批后心跳" --> API
|
||||
|
||||
API --> SeedsStorage
|
||||
```
|
||||
@@ -46,8 +46,8 @@ flowchart TB
|
||||
### 2.1 Master 服务端 (`server` & Web `dashboard`)
|
||||
- **工作流与多任务隔离**：支持多工作流并发隔离运行（`grid_points` 与 `task_queue` 增加 `workflow_name` 复合唯一索引），调度与重置操作严格隔离在单工作流作用域内。支持旧版 SQLite 数据库启动时无缝平滑迁移。
|
||||
- **安全中间件与 RBAC**：基于角色访问控制 (Admin / Node / Public) 划分 API 权限，内嵌 Bearer Token 校验、Governor / 漏桶算法限流中间件与 CORS 跨域控制，防御侧信道攻击与暴力破解。
|
||||
- **节点凭据生命周期管理**：支持 Worker 节点注册申请、管理员审批授权、Token 吊销与重新颁发全生命周期管理。
|
||||
- **任务调度与分配**：通过 `mq` 队列管理任务生命周期，响应 Worker 的 Claim 请求分配就绪任务。
|
||||
- **节点凭据生命周期管理**：支持 Worker 节点注册申请、管理员审批授权、Token 重新颁发（旧 token 失效）与节点停用/启用全生命周期管理。
|
||||
- **任务调度与分配**：调度器将 pending 网格点推入 `mq` 队列；Worker 以 **pull 抢占式** 领用任务（详见 [§5 任务调度模型](#5-任务调度模型-task-scheduling)）。
|
||||
- **状态维护与心跳监测**：后台离线检测线程定期标记超时未心跳的节点为 `offline`，并能将僵挂在超时节点上的任务自动回收到队列中（Requeue）。
|
||||
- **ESM 模块化 Web 看板**：前端采用 ESM 模块解耦设计（`state.js`, `api.js`, `components/`），支持节点凭据管理、工作流控制与全局 Toast 通知。
|
||||
|
||||
@@ -66,8 +66,9 @@ flowchart TB
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> Pending : 工作流注册生成网格点
|
||||
Pending --> Running : Worker 成功 Claim 抢占
|
||||
|
||||
Pending --> Queued : 调度器推入 mq 队列
|
||||
Queued --> Running : Worker 成功 Claim 抢占
|
||||
|
||||
state Running {
|
||||
[*] --> ExecutingChain
|
||||
ExecutingChain --> ColdStartChain : 默认冷启动 (lte->nc->nl)
|
||||
@@ -76,14 +77,18 @@ stateDiagram-v2
|
||||
SeedStepChain --> Synspec : 热启动收敛
|
||||
}
|
||||
|
||||
Running --> Completed : 计算成功 & 上传 .7 产物
|
||||
Running --> Pending : Worker 节点心跳超时/主动释放 (Requeue)
|
||||
Running --> Failed : 重试次数达到上限 / 彻底发散
|
||||
Running --> Converged : 计算成功 & 上传 .7 产物
|
||||
Running --> Pending : Worker 心跳超时/掉线 (Requeue, 直接回 Pending 等待重新派发)
|
||||
Running --> Failed : 无可邻近种子回退 / 彻底发散
|
||||
|
||||
Completed --> [*]
|
||||
Converged --> [*]
|
||||
Failed --> [*]
|
||||
```
|
||||
|
||||
> 状态值与 [`GridPointStatus`](file:///home/fmq/program/tlusty/tl208-s54/dcts/crates/common/src/models.rs#L237) 一一对应：
|
||||
> `pending` → `queued` → `running` → `converged` / `failed`。
|
||||
> Requeue 把 `running` 直接重置回 `pending`（不经过 `queued`），由调度器下一轮重新推入队列。
|
||||
|
||||
---
|
||||
|
||||
## 4. 容错与高可用设计 (Fault Tolerance)
|
||||
@@ -92,3 +97,56 @@ stateDiagram-v2
|
||||
2. **零文件扫描与连接并发缩流**：底层任务分批取配、排队清洗与邻接优化（Seed-Stepping）全链线依赖常驻内存的 SQlite 主从精算并调优收敛连接池配置（主库=8，队列=4 减免本地排他写冲突并发挂断）；去除了历史残存的高损及同步阻塞磁盘遍历 API，在确保零卡死响应的前提下提升查询搜索效力。
|
||||
3. **任务超时与流控平稳保护 (Stale & Requeue)**：服务端后台定期向已超时死挂的 `Running` （默认 >1800 秒）作业予以强退回转为 `Pending`；此外当操作维护员发起暂停或终止工作流行为时，将仅平滑洗退待调 `Queued` 项，悉心保育在途已投的 Worker 数值演算完整出计算归表，防假命题竞合。
|
||||
4. **多级退避与种子隔离**：若某点冷启动发散，自动隔离失败现场，依靠数据库记录寻找欧氏空间距离最匹配的热启动合拢 `.7` 气象序列；即便遇到底层强硬大步发散也不产生干扰并留存物理运行根系以便溯源。
|
||||
|
||||
---
|
||||
|
||||
## 5. 任务调度模型 (Task Scheduling)
|
||||
|
||||
### 5.1 Pull 抢占式模型（非服务端负载分发）
|
||||
|
||||
DCTS 的任务分发是 **Worker 主动拉取（pull）** 模型，**不是**服务端按节点负载推派（push）：
|
||||
|
||||
- **调度器**（[`schedule_pending_tasks`](file:///home/fmq/program/tlusty/tl208-s54/dcts/crates/server/src/scheduler.rs#L153)）只负责把 `pending` 网格点推入 `mq` 队列（`push_task`），不参与"分给哪个 node"的决策。
|
||||
- **Worker**（[领用主循环](file:///home/fmq/program/tlusty/tl208-s54/dcts/crates/node/src/worker.rs#L275)）只要 `active_slots < max_slots`，就持续向服务端发起 `claim` 请求抢任务。
|
||||
- **服务端** [`pop_task`](file:///home/fmq/program/tlusty/tl208-s54/dcts/crates/mq/src/sqlite_queue.rs#L145) 的出队决策**只看任务自身属性**，不看谁来领用：谁先抢到写锁、谁就拿到队首任务。
|
||||
|
||||
出队排序（难度优先 → 同难度先进先出）：
|
||||
|
||||
```sql
|
||||
SELECT task_id, payload FROM task_queue
|
||||
WHERE status = 'pending'
|
||||
ORDER BY wave ASC, created_at ASC
|
||||
LIMIT 1
|
||||
```
|
||||
|
||||
### 5.2 为什么不做服务端负载分发
|
||||
|
||||
关键观察：**Worker 满载后会主动停止领用**（[worker.rs](file:///home/fmq/program/tlusty/tl208-s54/dcts/crates/node/src/worker.rs#L280-L281)）：
|
||||
|
||||
```rust
|
||||
let active = self.active_slots.load(Ordering::Acquire);
|
||||
if (active as usize) < self.config.max_slots {
|
||||
match self.claim_task().await { /* 抢任务 */ }
|
||||
} else {
|
||||
sleep(Duration::from_secs(2)).await; // 满载：不 claim，等槽位释放
|
||||
}
|
||||
```
|
||||
|
||||
由此分两种工况：
|
||||
|
||||
| 工况 | 条件 | 是否会扎堆 | 负载分发是否需要 |
|
||||
|------|------|-----------|-----------------|
|
||||
| **稳态** | 任务数 ≥ 所有 node 总槽位 | 否——各 node 抢满 `max_slots` 即停止 claim，空出槽位者再去抢，**天然均衡** | 不需要 |
|
||||
| **稀疏态** | 任务数 < 总槽位（如调试用 2 个点） | 是——最快的 node 连续抢光少量任务 | 收益极小，省的仅是几个任务的串行墙钟时间 |
|
||||
|
||||
稳态（网格规模任务，如 sdB_cno 的 432 点）是实际生产场景，该场景下 pull 模型已自动达成负载均衡。稀疏态的扎堆是固有现象且代价可忽略（任务跑完即结束）。
|
||||
|
||||
引入服务端负载分发的**代价**反而更高：破坏 FIFO 可预测性、带来心跳负载数据滞后导致的退让抖动、增加队首饥饿风险。综合权衡，**当前 pull 模型是刻意选择，无需改为服务端负载分发**。
|
||||
|
||||
> **稀疏态调试建议**：若调试时确实希望任务分散到多个 node 观察，最省事的做法是把各 node 的 `DCTS_MAX_SLOTS` 设为 `1`——每个 node 抢 1 个即满载停止，自然分散，零代码改动、零风险。
|
||||
|
||||
### 5.3 出队优先级语义（wave + FIFO）
|
||||
|
||||
- **`wave ASC`（难度优先）**：网格点按 CNO 丰度之和（`cno_sum`）升序分组，低丰度（低难度、更易收敛）的点先出队。设计意图是"先易后难"——先跑出收敛点作为种子库，后续高难度点可借热启动种子收敛。
|
||||
- **`created_at ASC`（同难度 FIFO）**：同一 `wave` 内严格按推入队列的时间先后出队。
|
||||
- **跨工作流公平**：出队不按 `workflow_name` 分组，多个并发工作流的低难度点会先于任何工作流的高难度点出队，避免某工作流在高难度 wave 上饿死其他工作流的低难度点。
|
||||
|
||||
Reference in New Issue
Block a user