只是多兩個 Background Job，為什麼讓 Redis 記憶體暴增三倍？從 Hangfire 看需求背後的可靠性成本
· 預估閱讀時間： 25 分鐘
前言
之前有一個專案，需要在每一局遊戲中新增兩個 Background Job，從原本一局有 5 個 Background Job 變成 7 個。
乍看之下，這件事真的很容易被當成小改動。
不就是多兩個 Background Job 嗎？
結果上到 UAT 之後，Redis 的記憶體使用量直接暴增三倍，差點把 Redis 的記憶體吃到見底。
這件事情最有價值的地方，不是我們最後找到了哪幾個 Redis Key 變大，而是它提醒了我們一件很容易被忽略的事：
在高頻系統裡，每一個 Background Job 都不是免費的。
Background Job 不單單只是「排程執行」這麼簡單的一件事而已。
它背後還包含 Job metadata、serialized arguments、state history、retry、failed details、Batch metadata、TTL 保留，以及後續清理成本。
這些成本如果沒有在需求設計階段就被看見，那它最後可能就會在上線之後對 Redis 帶來極大的壓力，並且對系統的穩定度帶來極高的風險。