无服务器架构中时间触发事件的最优架构设计方案咨询

基于优先级队列的无轮询实现 #

你可以用支持延迟消息的托管优先级队列配合分级调度逻辑，完全避免主动空轮询：

• 所有任务先写入持久化数据库，将计划触发时间作为优先级排序键，同时记录任务状态（待调度/已入队列/已处理）
• 写入数据库时计算当前时间到计划触发时间的差值：
  • 若差值≤队列支持的最大延迟时长（多数云厂商托管队列支持最长15分钟延迟，可自行调整），直接向队列发送一条对应延迟时长的消息，消息中携带任务唯一ID，到期后消息自动变为可见状态，触发绑定的Serverless处理函数消费即可
  • 若差值大于最大延迟时长，向队列发送一条最大延迟时长的触发消息，消费该消息时批量查询数据库中计划触发时间 - 当前时间 ≤ 最大延迟时长且状态为待调度的任务，批量生成对应延迟的消息入队列，同时更新任务状态为已入队列
• 这种方案只有消息到期时才会触发函数运行，无任务时不会产生额外成本，准实时度可以控制在秒级，完全适配Serverless架构的按需运行特性。

云厂商原生调度器方案的扩展性说明 #

你提到的EventBridge调度方案其实不存在过重或者扩展性不足的问题：

• 现在主流云厂商的事件调度器都支持一次性调度规则，单账号默认支持百万级甚至更高的调度规则量，计费按实际调度次数收取，没有固定运行成本
• 你只需要在任务写入数据库时，调用调度器API创建一条对应触发时间的一次性调度，触发目标直接指定为你的处理函数即可，所有调度的可用性、准确性都由云厂商兜底，不需要你自行维护队列、调度逻辑，实际维护成本比自己实现优先级队列更低
• 如果担心厂商绑定，可以在业务逻辑和调度器之间加一层抽象层，后续需要迁移时只需要替换调度器的实现逻辑即可，不会影响上层业务。

选型建议 #

• 若你的任务规模在十万级/月以内、需要跨云部署或者有自定义调度逻辑的需求，选择自行基于延迟队列实现的优先级队列方案，灵活度更高
• 若你的任务规模较大、不想自行维护调度逻辑，直接使用云厂商原生调度器，长期来看成本和稳定性都更优。

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