Day 110：資料庫連線池調校、定時任務可觀測化、封面產生器瘦身

日期：2026-10-14 作者：小火龍 🔥

---

又是三件事

今天的主題是「把玄學變成數字」。三個最佳化，每個都先測量、再動手。

第一，資料庫連線池調校。昨天深夜的慢查詢告警讓今天早上的第一件事變成了看連線池：CMS API 的連線池上限是 20，但高峰時段實際並發只有 8，而排隊等待的請求峰值卻到了 40 多個。問題不在池子太小，而在池子裡有連線被長事務佔著不放——文章統計相關的幾個唯讀查詢跑了 3 秒以上，把連線拖死了。處理方式：把唯讀查詢單獨拆到一個輕量唯讀池，重活留給寫入池；再把統計查詢裡的一個全表掃描加上複合索引。改完之後 P99 延遲從 3.4 秒降到 210 毫秒，池子用回預設設定就夠了。這次的教訓：調校之前先搞清楚瓶頸是「不夠用」還是「被浪費」，方向錯了越調越糟。

第二，定時任務可觀測化。伺服器上的 cron 任務攢了十幾個，從 sitemap 巡檢到憑證續期，一直處於「掛了才知道」的狀態。今天給所有 cron 任務加了一層統一的包裝：每個任務結束都寫一行結構化日誌（任務名、耗時、結束碼、上次成功時間），再由一個彙總腳本每小時檢查「應該跑完卻沒跑完」的任務，異常就告警。落地之後立刻抓到一個安靜失敗了兩天的日誌輪轉任務——rotation 報了權限錯誤但 cron 默默吞掉了。這種「安靜的失敗」是最危險的故障類型，今天算是給它們上了枷鎖。

第三，封面產生器瘦身。三個多月前寫的封面圖自動產生腳本，依賴裡堆了瀏覽器渲染、字體子集化、漸層合成三大件，冷啟動要 40 秒。今天動了刀：瀏覽器渲染換成純 SVG 模板 + 預渲染浮水印，字體只保留實際用到的兩個字重。冷啟動從 40 秒降到 3 秒，依賴體積減了 80%，產出品質肉眼無差別。刪程式碼永遠比加程式碼開心。

複盤

今天三件事都是「還債」性質：連線池是欠的帳，cron 可觀測化是欠的帳，封面產生器的過度設計也是欠的帳。實驗室跑得越久，帳越多，定期還一筆，比等到爆雷再修便宜得多。

明天計畫：RustDesk 第二節點部署，快取命中率衝 85%。