如何实现按首次事件触发、最多每30分钟一次的高开销计算聚合窗口？

核心逻辑梳理 #

针对每个item的变更事件，我们需要实现固定时长的一次性窗口：首次事件触发30分钟倒计时，窗口内后续事件不延长/重置窗口；到期后执行一次高开销计算，后续事件则触发新窗口。所有item的窗口完全独立，互不干扰。

推荐数据结构与实现方案 #

1. 核心存储：线程安全哈希表（或分布式哈希缓存） #

用哈希表存储每个item的窗口状态，键为item ID，值包含两个字段：

• expire_time：窗口到期时间戳
• scheduled：标记是否已提交延迟计算任务（避免重复调度）

对于50万级别的item，每个记录仅占用几十字节内存，单机内存完全可以承载；如果是分布式场景，用Redis的Hash结构即可实现高并发读写与持久化。

2. 延迟任务调度：延迟队列 #

搭配延迟任务队列处理到期的计算任务，核心逻辑如下：

• 当item的首次事件到达时：
  1. 检查哈希表中是否存在该item的记录
  2. 若不存在，计算expire_time = 当前时间 + 30分钟，将记录存入哈希表，并标记scheduled = true
  3. 向延迟队列提交一个在expire_time触发的计算任务，任务携带item ID
• 当item的非首次事件到达时：直接忽略，不做任何操作（窗口已启动，无需重置）
• 延迟任务到期触发时：
  1. 从哈希表中查询该item的状态，确认expire_time已到期
  2. 通过CAS（Compare-And-Swap）操作锁定任务，确保仅一个线程执行计算（避免重复执行）
  3. 执行高开销计算
  4. 计算完成后，删除哈希表中该item的记录，允许后续事件触发新窗口

3. 异常处理与优化 #

• 系统重启恢复：使用持久化的分布式缓存（如Redis开启RDB/AOF），重启后可恢复未到期的窗口状态；若用单机哈希表，可在重启后通过监听事件重新创建窗口（少量计算延迟可接受）
• 高并发场景：哈希表需支持原子操作（如Redis的HSETNX），避免多线程同时创建窗口；延迟队列需支持高吞吐量，分布式场景下用Redis ZSet实现（将expire_time作为score，定期扫描到期任务）

与数据库+Cron方案的对比优势 #

• 负载均匀：计算任务分散在各个item的窗口到期时间执行，不会出现集中负载骤增的情况
• 极低存储开销：仅存储窗口状态，无需保存所有事件，内存占用远低于数据库存储
• 灵活调整窗口时长：只需修改expire_time的计算逻辑，无需改动数据库增删操作，适配30秒到30分钟的任意窗口

内容的提问来源于stack exchange，提问作者John Snow