配置热重载功能

November 20, 2025 · View on GitHub

概述

TrendHub 支持配置热重载（Hot Reload）功能，当你在 Web 界面修改配置并保存后，系统会自动重新加载配置并更新相关组件，无需重启程序。

支持的配置项

以下配置项的更改会自动生效：

1. 推送窗口配置 (Push Window)

notification:
  push_window:
    enabled: true              # 启用/禁用推送窗口
    time_range:
      start: "18:00"           # 修改推送开始时间
      end: "22:00"             # 修改推送结束时间
    once_per_day: true         # 每天只推一次/可多次推送

生效方式:

启用推送窗口 → 自动启动调度器
禁用推送窗口 → 自动停止调度器
修改时间范围 → 自动重启调度器使用新时间

日志输出:

Reloading scheduler configuration...
Scheduler configuration changed (enabled: false -> true, time: 20:00-22:00 -> 18:00-22:00)
Restarting scheduler with new configuration...
Scheduler restarted successfully

2. 报告模式 (Report Mode)

report:
  mode: daily                  # daily / current / incremental
  rank_threshold: 10

生效方式:

current → daily: 自动启动后台收集器
daily → current: 自动停止后台收集器
daily → incremental: 停止收集器
其他切换：自动更新模式

日志输出:

Reloading configuration for TaskRunner...
Report mode changed: current -> daily
Creating and starting daily collector (mode changed to daily)...
Daily collector started, collecting data every 10m0s
Configuration reloaded successfully

3. 爬虫配置 (Crawler Config)

crawler:
  request_interval: 600000     # 爬取间隔（毫秒）

生效方式:

daily 模式下，收集器会使用新的爬取间隔
自动重启收集器

日志输出:

Reloading daily collector configuration...
Daily collector configuration changed (interval: 5m0s -> 10m0s)
Restarting daily collector with new configuration...
Daily collector restarted successfully

4. 推送渠道配置 (Webhooks)

notification:
  webhooks:
    feishu_url: "https://..."
    bark_device_key: "xxx"
    # ... 其他推送渠道

生效方式:

下次推送时自动使用新配置
无需重启任何组件

5. 关键词配置 (Keywords)

AI
人工智能
...

生效方式:

下次运行任务时自动加载新关键词
无需重启组件

使用方法

通过 Web 界面修改配置

打开 Web 界面：http://localhost:8080
点击"系统配置"或"关键词配置"标签
修改配置内容
点击"保存配置"按钮
系统自动重载配置 ✓

界面提示:

配置已保存 ✓

通过直接编辑文件（需要手动触发）

如果你直接编辑 config.yaml 文件，需要：

选项 1: 通过 Web 界面触发重载

打开 Web 界面
点击任意配置标签
点击"保存配置"（即使没有修改）

选项 2: 重启程序

# Ctrl+C 停止
# 重新启动
./trendhub -web

重载过程

1. 推送窗口启用/禁用

场景 A: 禁用推送窗口

# 修改前
notification:
  push_window:
    enabled: true

# 修改后
notification:
  push_window:
    enabled: false

系统行为:

保存配置文件
检测到 enabled: true → false
停止调度器
日志输出: "Scheduler stopped (push window disabled)"

场景 B: 启用推送窗口

# 修改前
notification:
  push_window:
    enabled: false

# 修改后
notification:
  push_window:
    enabled: true

系统行为:

保存配置文件
检测到 enabled: false → true
启动调度器
日志输出: "Starting scheduler (push window enabled)..."

2. 推送时间窗口修改

场景: 修改推送时间

# 修改前
time_range:
  start: "20:00"
  end: "22:00"

# 修改后
time_range:
  start: "18:00"
  end: "19:00"

系统行为:

保存配置文件
检测到时间范围变化
停止旧的调度器
使用新时间启动调度器
日志输出: "Scheduler restarted successfully"

3. 报告模式切换

场景: 切换到 daily 模式

# 修改前
report:
  mode: current

# 修改后
report:
  mode: daily

系统行为:

保存配置文件
检测到模式变化
创建并启动 DailyCollector
立即开始收集数据
日志输出: "Daily mode: continuous data collection started"

场景: 从 daily 切换到其他模式

# 修改前
report:
  mode: daily

# 修改后
report:
  mode: current

系统行为:

保存配置文件
检测到模式变化
停止 DailyCollector
清空当前内存缓存（下次任务使用新模式）
日志输出: "Stopping daily collector (mode changed from daily)..."

4. 爬取间隔修改（daily 模式）

场景: 修改爬取间隔

# 修改前
crawler:
  request_interval: 300000  # 5分钟

# 修改后
crawler:
  request_interval: 600000  # 10分钟

系统行为（仅在 daily 模式下）:

保存配置文件
检测到间隔变化
停止旧的收集器
使用新间隔启动收集器
日志输出: "Daily collector restarted successfully"

日志监控

查看配置重载日志

# 实时查看日志
./trendhub -web 2>&1 | grep -E "(Reload|Restart|configuration)"

# 或者如果日志输出到文件
tail -f trendhub.log | grep -E "(Reload|Restart|configuration)"

关键日志消息

配置重载开始:

Reloading configuration for TaskRunner...

调度器重载:

Reloading scheduler configuration...
Scheduler configuration changed (enabled: false -> true, ...)
Restarting scheduler with new configuration...
Scheduler restarted successfully

收集器重载:

Reloading daily collector configuration...
Daily collector configuration changed (interval: 5m0s -> 10m0s)
Restarting daily collector with new configuration...
Daily collector restarted successfully

配置重载完成:

Configuration reloaded successfully

注意事项

1. 备份机制

每次保存配置时，系统会自动创建备份文件：

config/config.yaml      # 当前配置
config/config.yaml.bak  # 备份（上一次的配置）

如果配置出错，可以恢复：

cp config/config.yaml.bak config/config.yaml

2. 配置验证

系统会在保存时进行基本的 YAML 格式验证，但不会验证所有配置项的有效性。

建议: 修改重要配置前先备份

cp config/config.yaml config/config.yaml.$(date +%Y%m%d_%H%M%S)

3. 并发修改

如果多人同时修改配置，后保存的会覆盖先保存的。

建议:

多人环境下使用版本控制（Git）
或约定由一人管理配置

4. 正在运行的任务

配置重载不会中断正在运行的任务。

行为:

如果任务正在执行，等任务完成后新配置才会在下次任务中生效
调度器和收集器会立即使用新配置

5. 数据一致性

daily 模式:

切换到其他模式时，当前内存缓存会保留
但下次推送会使用新模式的数据

incremental 模式:

已推送记录保留在数据库中
切换模式不会清空推送历史

故障排查

问题 1: 修改配置后没有生效

检查:

是否通过 Web 界面保存的？
查看日志是否有重载信息
检查配置文件是否真的改了

解决:

# 查看当前配置
cat config/config.yaml

# 查看日志
tail -f trendhub.log

问题 2: 调度器没有重启

可能原因:

配置没有实际变化
推送窗口被禁用

检查日志:

Scheduler configuration unchanged, no restart needed

问题 3: daily 收集器没有启动

可能原因:

mode 不是 "daily"
配置加载失败

检查日志:

grep "Daily collector" trendhub.log

手动触发:

修改 mode 为 "daily"
保存配置
查看日志确认启动

问题 4: 配置保存失败

错误消息: "Failed to reload configuration"

可能原因:

YAML 格式错误
配置文件权限问题
必需字段缺失

解决:

# 检查 YAML 语法
yamllint config/config.yaml

# 恢复备份
cp config/config.yaml.bak config/config.yaml

# 重新修改并保存

高级用法

通过 API 触发配置重载

虽然 Web 界面会自动触发重载，但你也可以手动调用：

# 保存配置后会自动重载
curl -X POST http://localhost:8080/api/config \
  -H "Content-Type: application/json" \
  -d '{"content": "..."}'

监控配置变化

# 监控配置文件变化
watch -n 5 'ls -lh config/config.yaml*'

# 监控重载事件
tail -f trendhub.log | grep --line-buffered "Reload"

配置变更通知

可以添加脚本监控配置变更：

#!/bin/bash
# watch_config.sh

CONFIG_FILE="config/config.yaml"
LAST_MTIME=$(stat -c %Y "$CONFIG_FILE")

while true; do
    CURRENT_MTIME=$(stat -c %Y "$CONFIG_FILE")
    if [ "$CURRENT_MTIME" != "$LAST_MTIME" ]; then
        echo "配置文件已更改！"
        # 可以发送通知
        LAST_MTIME=$CURRENT_MTIME
    fi
    sleep 10
done

性能影响

配置热重载对性能的影响很小：

重载时间: < 100ms
内存开销: 几乎为零（只是重新读取配置）
CPU 使用: 极低（仅在重载时短暂增加）

测试数据（供参考）:

操作	耗时	影响
保存配置	~10ms	无
重载配置	~50ms	无
重启调度器	~20ms	无
重启收集器	~30ms	无

最佳实践

修改前备份: 重要配置修改前先备份
逐步修改: 一次只改一个配置项，便于排查问题
监控日志: 修改后查看日志确认生效
测试验证: 修改后测试相关功能
文档记录: 记录重要的配置变更

版本信息

功能版本: v2.3.0
添加时间: 2025-11-20
支持的配置: 推送窗口、报告模式、爬虫间隔、推送渠道、关键词

概述

支持的配置项

使用方法

通过直接编辑文件（需要手动触发）

重载过程

日志监控

查看配置重载日志

关键日志消息

注意事项

故障排查

高级用法

监控配置变化

配置变更通知

性能影响

最佳实践

版本信息

相关文档