2. 调度模型对比：定时调度、事件驱动调度、混合调度模型的优劣分析

日志平台的核心，说白了就是「什么时候干活」的问题。

我见过不少团队，一开始随便选个调度模型，等日志量涨到每天几十 TB 时，才发现系统根本扛不住。调度模型选错了，后面再怎么优化都像在给破桶补洞。

今天咱们就把三种主流模型掰开揉碎聊清楚：定时调度、事件驱动调度、还有混合调度。每种我都踩过坑，咱们边聊边看。

2.1 定时调度模型

定时调度，就是按预设的时间点触发任务。比如每天凌晨 2 点跑一次日志归档，或者每 5 分钟拉一次应用日志。

优点

• 实现简单：Linux Cron、Quartz、xxl-job 都能直接上手，几乎零学习成本。
• 可预测性强：运维排班、资源预留都很方便。我知道凌晨 2 点要跑归档，提前把计算资源空出来就行。
• 适合批量处理：日志压缩、冷存储迁移这类任务，定时跑最省心。

缺点

• 响应延迟：如果日志在 2:01 产生，但任务每 5 分钟跑一次，最坏情况要等接近 5 分钟才能处理。
• 资源浪费：没日志时也在空转。我曾经见过一个系统，凌晨 3 点日志量几乎为零，但定时任务照常拉起 20 个线程——纯属浪费。
• 高峰拥堵：所有任务都挤在整点或半点，CPU 和 IO 瞬间飙高，反而拖慢正常业务。

// 定时调度伪代码示例
public class TimedLogCollector {
    @Scheduled(cron = "0 */5 * * * ?")  // 每5分钟执行一次
    public void collectLogs() {
        // 拉取过去5分钟的日志
        List<LogEntry> logs = fetchLogs(now().minusMinutes(5), now());
        process(logs);
    }
}

2.2 事件驱动调度模型

事件驱动，就是「有事才干活」。日志产生了、消息到了、状态变了——这些事件触发对应的处理任务。

我个人习惯把事件驱动比作「急诊室模式」：病人来了才处理，没人就休息。资源利用率高，响应也快。

优点

• 实时性高：事件产生后几乎立即触发处理，延迟通常在毫秒级。
• 资源利用率好：没事件时系统几乎零负载，不像定时任务那样空转。
• 天然解耦：生产者只管发事件，消费者只管处理，中间通过消息队列（Kafka、RabbitMQ）连接，扩展性极强。

缺点

• 实现复杂：需要维护事件总线、处理背压、保证消息不丢不重。
• 流量不可控：突发流量可能导致任务积压。我记得有一次双十一大促，日志量瞬间暴涨 10 倍，事件队列直接撑爆，丢了不少数据。
• 调试困难：事件流是异步的，出了问题很难复现。你想想看，一个日志从产生到最终入库，中间经过五六个事件处理器，哪个环节出错了？

// 事件驱动调度伪代码示例
public class EventDrivenLogProcessor {
    @EventListener
    public void onLogEvent(LogEvent event) {
        // 事件到达后立即处理
        LogEntry entry = event.getLogEntry();
        if (entry.getLevel() == Level.ERROR) {
            alertService.sendAlert(entry);  // 实时告警
        }
        storageService.save(entry);
    }
}

2.3 混合调度模型

混合调度，就是把定时和事件驱动结合起来。这也是我目前在大多数生产环境推荐的做法。

核心思路很简单：事件驱动处理实时任务，定时调度处理批量任务和兜底。

典型架构

• 实时链路：日志产生 → 事件触发 → 实时解析 → 实时索引 → 实时告警
• 批量链路：定时触发 → 日志归档 → 冷存储迁移 → 过期清理
• 兜底链路：定时检查事件队列是否有积压，如果有则触发补录任务

优点

• 兼顾实时与批量：关键日志秒级处理，非关键日志定时汇总，各取所需。
• 容错性强：事件驱动挂了，定时任务还能兜底补数据。我遇到过 Kafka 集群宕机 2 小时，全靠定时任务从原始日志文件里重新拉取，数据一条没丢。
• 资源可控：批量任务可以安排在低峰期，避免和实时任务抢资源。

缺点

• 架构复杂：需要同时维护两套调度引擎，配置项翻倍。
• 数据一致性难保证：事件链路和定时链路可能处理同一批数据，需要做去重。
• 运维成本高：排查问题时，既要看事件链路日志，又要看定时任务日志。

// 混合调度伪代码示例
public class HybridLogScheduler {
    // 事件驱动：实时处理
    @EventListener
    public void onLogEvent(LogEvent event) {
        realtimeProcessor.process(event);
    }

    // 定时调度：批量归档 + 兜底补录
    @Scheduled(cron = "0 0 2 * * ?")  // 每天凌晨2点
    public void batchArchive() {
        // 检查事件链路是否有遗漏
        List<String> missedLogs = checkMissedLogs();
        if (!missedLogs.isEmpty()) {
            log.warn("发现 {} 条遗漏日志，启动补录", missedLogs.size());
            replayLogs(missedLogs);
        }
        // 执行归档
        archiveOldLogs();
    }
}

2.4 三种模型对比总表

对比维度	定时调度	事件驱动调度	混合调度
实时性	低（分钟级）	高（毫秒级）	高（实时+批量）
实现复杂度	低	中	高
资源利用率	低（有空转）	高（按需触发）	中高
容错能力	中（依赖重试）	中（依赖消息持久化）	高（双重保障）
运维成本	低	中	高
适用场景	日志归档、冷存储、报表生成	实时告警、在线分析、流处理	大规模日志平台、企业级 ELK

2.5 我如何选型？

说实话，没有银弹。我一般按这几个原则来选：

1. 日志量 < 100 GB/天：纯定时调度就够了。别折腾，简单就是王道。
2. 日志量 100 GB ~ 10 TB/天：事件驱动为主，定时任务做辅助归档。这个量级下，实时性开始变得重要。
3. 日志量 > 10 TB/天：必须上混合调度。我目前在维护的一个平台，每天处理 50+ TB 日志，纯事件驱动扛不住突发，纯定时又满足不了实时告警需求，混合调度是唯一选择。

2.6 调度模型选型决策流程图

下面这张图是我自己总结的选型流程，每次搭建新平台时都会拿出来对照一下：

2.7 避坑总结

最后分享几个我亲身踩过的坑：

• 别迷信纯事件驱动：我曾经在一个项目里全面拥抱事件驱动，结果消息队列挂了，整个日志平台瘫痪了 6 小时。后来加了定时兜底任务，再也没出过类似问题。
• 定时任务别忘了加随机偏移：所有定时任务都设在整点，会导致资源争抢。我习惯给每个任务加 0~300 秒的随机偏移，效果立竿见影。
• 混合调度要做好链路追踪：同一个日志可能被事件链路和定时链路各处理一次，必须用唯一 ID 去重。我一般用日志文件的 inode + offset 作为唯一标识。
• 监控不能少：不管选哪种模型，都要监控任务积压、执行耗时、失败率。没有监控的调度系统，就像蒙眼开车——迟早出事。