以数据库为主的报表调度系统设计

Question

问题

• 我们有 ~50k 定期通过电子邮件发送给客户的预定财务报告
• 报告有自己的交付频率（日期和时间格式 - 由客户配置）
  • 每周
  • 每天
  • 每小时
  • 仅限工作日
  • 等

当前架构

• 我们有一个名为report_metadata 的表，其中包含报告信息

  • report_id
  • report_name
  • report_type
  • report_details
  • next_run_time
  • last_run_time
  • 等等……

• 每周，我们的 调度程序 服务的所有 6 个实例都会轮询 report_metadata 数据库，提取将在下一周交付的所有报告的元数据，并将它们放入 内存中的定时队列。

• 仅在 ma​​ster/leader 实例（这是 6 个实例之一）中：

  • 定时队列中的数据在适当的时间弹出
  • 已处理
  • 进行了几次 API 调用以获得完整的当前/最新报告
  • 报告通过电子邮件发送给客户

• 其他 5 个实例什么都不做 - 它们只是为了冗余而存在

建议的架构

数字：

• db 最多可以处理 1000 个并发连接 - 这已经足够了
• 现有报告总数 (~50k) 在近期/远期不太可能变得更大

解决方案：

• 不是每周轮询report_metadata db 并将数据存储在内存中的定时队列中，所有 6 个实例将每 60 秒轮询一次report_metadata db（10 秒每个实例的偏移量）
• 平均而言，调度程序将尝试每 10 秒接一次工作
• 提取next_run_time 在过去 的任何单个报告的数据，锁定表格行，然后通过该报告处理/交付给客户具体实例
• 报表处理成功后，表行解锁，报表的next_run_time、 last_run_time等更新

一般来说，数据库作为master，进程的各个实例可以独立工作，并且数据库确保它们不重叠。

如果您能告诉我所提议的架构是否为：

• 一个好的/正确的解决方案
• 可以/应该索引哪些表列
• 任何其他注意事项

Answer 1

我为一个程序开发了一种不同类型的调度器，该程序报告了每月/每周特定时刻的分析，我所做的是将这些报告结合到所谓的基于业务周期的时间时刻。这些时刻是在“新一周的开始”、“本月的开始”、“D/W/M/Q/Y 的开始/结束”。所以我标准化了发送报告的时刻并添加了 id到一个包含报告详细信息的表格中。-现在您将想法添加到您在需要时删除它的周期中，您可以通过添加一个标签来做到这一点（EOD（一天结束）/EOM（月末） SOW（一周开始）等，等，等）。

因此，您可以索引客户希望接收报告并在该轨道上构建的时刻。希望此评论可以帮助您应对挑战。

Answer 2

按所有 6 个实例简单地查询该元数据表以检查哪个是您建议的下一个要处理的报告似乎很好。

虽然有一种交错的方法，每 60 秒检查一次，对您的服务器偏移 10 秒，这似乎很奇怪。您现在有 6 台服务器，但这可能会改变。另外我不明白您建议的“锁定”，为什么现在只需在行上设置一个标志，例如 [State] = “processing”，然后下一个调度程序知道跳过该行并继续下一个可用的行.处理完运行后，您可以简单地更新 [Date_last_processed] 列，或者可能像 [last_cycle_complete] = 'YES' 这样的内容。

或者，您可以让一个服务器进程遍历表，并针对每个可用行，以循环方式将其发送到其中一个实例（或跟踪谁忙谁不忙） t)。