触发机制：定时触发、事件触发、手动触发、条件触发

触发机制，说白了就是「什么时候干活」的问题。

我在做自动化平台时，见过太多团队把触发搞得很复杂。其实核心就四种：定时、事件、手动、条件。把这四种吃透了，你就能应对 90% 的场景。

一、定时触发

定时触发是最直观的。你设定一个时间点，系统到点就执行。我习惯把它分成两类：

• 固定频率：比如每 5 分钟跑一次，或者每天凌晨 3 点跑
• Cron 表达式：更灵活，可以精确到秒、分、时、日、月、周

我在项目中遇到过一个问题：定时任务如果跑超时了怎么办？嗯，这里要注意——一定要设置超时阈值。我曾经有个定时任务跑了 8 小时没结束，直接把后续任务全堵死了。

# 一个典型的 Cron 表达式示例
# 每天凌晨 2:30 执行
30 2 * * * /usr/local/bin/run_test.sh

# 每 15 分钟执行一次
*/15 * * * * /usr/local/bin/check_health.sh

二、事件触发

事件触发是「发生了什么事，我就干活」。这是最灵活的方式。

你想想看，一个实验平台里，事件可以多到数不清：

• 文件上传完成
• 数据库记录变更
• API 调用返回
• 传感器数据到达
• 另一个工作流结束

我个人习惯把事件触发分成两种模式：

模式	说明	适用场景
推送模式	事件源主动通知系统	实时性要求高，比如 Webhook
轮询模式	系统定期检查事件是否发生	事件源不支持推送，比如文件系统

事件触发有个好处——解耦。事件源不需要知道谁在监听，监听者也不需要知道事件源内部细节。这就是典型的观察者模式。

三、手动触发

手动触发，说白了就是「人按按钮」。别小看它，很多场景下这是最可靠的。

我见过一些团队，把所有流程都自动化了，结果出了问题想手动干预都找不到入口。嗯，这其实是个设计缺陷。

手动触发通常有三种形式：

1. 一键执行：点击按钮立即运行
2. 带参数执行：用户可以传入自定义参数
3. 批量执行：选择多个任务一起跑

手动触发还有一个妙用——调试。在开发阶段，你肯定不想等定时器或者等事件发生。手动触发能让你随时验证逻辑。

四、条件触发

条件触发是「如果满足条件，就执行」。这是最智能的触发方式。

条件触发可以基于：

• 数据阈值：比如温度超过 50°C 就启动冷却
• 状态变化：比如实验状态从「进行中」变成「已完成」
• 组合条件：多个条件同时满足才触发

# 条件触发伪代码示例
if temperature > 50 and humidity < 30:
    trigger_workflow("emergency_cooling")
elif file_size > 100MB:
    trigger_workflow("compress_file")
else:
    log("no condition met")

条件触发和事件触发容易混淆。区别在哪？事件触发是「发生了」，条件触发是「满足了」。举个例子：文件上传完成是事件，文件大小超过 1GB 是条件。

四种触发机制的对比

触发类型	触发源	实时性	可控性	典型场景
定时触发	时间	低	高	定时报告、夜间批处理
事件触发	外部事件	高	中	文件上传、API 回调
手动触发	用户操作	即时	最高	调试、紧急干预
条件触发	数据/状态	中	低	异常检测、自动扩缩容

实际项目中的组合使用

说实话，真实项目里很少只用一种触发。我做过的一个实验平台，就是四种混着用：

• 每天早上 8 点定时触发环境检查
• 实验数据到达时事件触发分析流程
• 运维人员可以手动触发回滚操作
• 当错误率超过 5% 时条件触发告警流程

知识体系图

这张图把四种触发机制的关系理清楚了。你看，它们不是互斥的，而是互补的。一个成熟的工作流系统，应该支持这四种机制的灵活组合。