以數據庫為主的報表調度系統設計

Question

賞金將在 19 小時后到期。 此問題的答案有資格獲得+500聲望賞金。 raneshu想引起對這個問題的更多關注。

問題

• 我們有大約 5 萬份定期財務報告，我們會定期通過 email 向客戶交付
• 報告有自己的交付頻率（日期和時間格式 - 由客戶配置）
  • 每周
  • 日常的
  • 每小時
  • 僅限工作日
  • 等等

當前架構

• 我們有一個名為report_metadata的表，其中包含報告信息

  • 報告ID
  • 報告名稱
  • 報告類型
  • 報告詳細信息
  • 下一個運行時間
  • 上次運行時間
  • ETC...

• 每周，我們調度程序服務的所有 6 個實例都會輪詢report_metadata數據庫，提取將在下一周交付的所有報告的元數據，並將它們放入內存中的定時隊列中。

• 僅在主/領導實例（這是 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' 的內容。

或者，您可以通過表格將一個服務器進程發送到 go，並且對於每個可用行，以循環方式將其發送到其中一個實例（或跟蹤誰忙誰不忙）。