第二十日：Queue 全線啟動，Redis 與 Actor Pool 的節奏之舞 🎶

一、開場：分散式的節奏感

今天的進展讓我真正感受到「系統開始活了」。
過去幾天在 Redis Queue、Actor Pool、以及通知發送機制的重構終於成形，
從 API → PostgreSQL → Redis → Actor → Teams，全線串接成功。

這不只是讓代碼能跑，而是讓整個系統「有節奏」地運作。
Redis 成為心臟，Actor 成為血管，訊息在其中流動，就像心跳般有規律。

二、從混亂到秩序：Queue 重構的核心

前幾天還是 FIFO 單佇列的混亂場面：
每個 Pod 都在爭搶任務、彼此干擾、甚至重複發送。
今天我們終於讓 Queue 變得有條理、有層次。

🎯 主要改進：

1. SETNX 防重複機制
   利用 Redis 的 SETNX 指令，在任務入列時檢查 key 是否存在，
   若存在就拒絕入列，確保多 Pod 情境下的唯一性。

2. 三層優先序佇列

   • High / Normal / Low 三層分流，按層級消費。
   • 消費端採用 BRPOP 機制，優先取高階任務。
   • 避免高流量下低優先任務永遠被餓死，後續會加上公平機制。

3. Actor Pool 重生

   • 池化控制併發數（預設 10）
   • 當 Pool 滿時暫停拉取，避免無謂的競爭
   • 每個 Actor 綁定唯一 ID，追蹤任務流向

三、代碼層修正紀錄

從今日 log 可以看出幾個重點修復：

• Teams 憑證統一管理：AppID 與 TenantID 統一來源，OAuth 流程穩定。
• Notification Data Load 修正：修掉 Activity must include text 錯誤，確保訊息內容完整。
• Actor Pool 滿載測試：同時啟動 10 個 Actor，成功限制併發，無錯誤。
• 健康檢查與 Log 分級：新增 /health endpoint、info/error 分級。

四、人生如 Queue：哲學時間

這次改造 Redis Queue，有種哲學味。
因為寫著寫著，我突然想到，人生其實也該有「優先序」。

• 不能每件事都 urgent，不然就沒有重點。
• 該刪的 code 該砍的 feature 要果斷，不然只會越拖越亂。
• 重構不是「改名字」，而是「改行為」。

最難的不是 coding，而是決定「先做什麼」。
這件事不只適用於工程，也適用於人生。

五、系統觀察筆記

🧩 Queue 運行狀況：

⚙️ 性能分析：

• 平均延遲：230ms
• 高優先任務處理時間：<100ms
• Pool 滿載運作時間：13 秒
• 無重複執行記錄

🚨 常見錯誤

六、明日計畫：從穩定到可視化

明天的主題將是「讓系統被看見」。
我打算導入 Prometheus metrics 與 Grafana dashboard：

• Redis Queue 長度、成功率、錯誤率視覺化
• Actor Pool 使用率與併發監控
• 通知發送延遲趨勢圖

這不只是「好看」，而是「好懂」。
畢竟，沒有監控的系統，就像沒有儀表板的飛機。

七、感想：當 Queue 動起來，整個系統都順了

今天看到第一條成功發送的 Teams 訊息，我真的笑出來。
那不是一條訊息，而是整個架構的里程碑。

當初那堆 error log、死鎖、重複發送的地獄，終於走出來了。
系統開始穩定、有節奏、有生命。

「Queue 穩了，世界就不亂了。」

✍️ Day20 收工心得
重構不是一次性的勝利，而是一種長期抗戰。
每次壓測、每次修 bug、每次 review，
都讓這個系統更接近可被信任的樣子。

明天，我要讓這個會「呼吸」的 Queue，學會「說話」。
下一步，就是監控、報表、與警示。