在前兩篇文章中，我們探討了 FastAPI 內建的 BackgroundTasks 和 Thread Pool 機制。BackgroundTasks 簡單卻不可靠，而 Thread Pool 解決了阻塞問題，但任務的生命週期依然與 Web 應用程式綁在一起。

這些內建工具在許多情境下都已足夠，但當你的應用規模擴大，遇到以下挑戰時，它們就顯得力不從心了：

• 可靠性：如果發送電子報的任務在執行中，伺服器卻意外重啟了，怎麼辦？
• 擴展性：如果每秒有上百個影片需要轉檔，單一伺服器的計算資源撐得住嗎？
• 解耦：為什麼 Web 伺服器需要關心圖片處理的細節？它應該只負責快速回應使用者請求。

為了解決這些問題，我們需要引入一個更強大的架構模式：任務佇列 (Task Queue)。

任務佇列的核心思想

任務佇列系統將「任務的發布者」與「任務的執行者」徹底分開。它主要由三個角色組成：

1. 生產者 (Producer)

   • 就是我們的 FastAPI 應用程式。它的職責很單純：當需要執行一個耗時任務時，它只需要將任務的描述（例如「請將這個影片轉為 720p」）打包成一則訊息，然後丟到一個「中間人」那裡。完成這個動作後，它就可以立刻回應使用者。

2. 中間人 (Broker)

   • 這是一個獨立的訊息服務，最常見的選擇是 Redis 或 RabbitMQ。它就像一個可靠的「任務待辦清單」。Broker 收到生產者發來的任務訊息後，會將其安全地儲存起來，等待執行者來領取。因為它是獨立服務，即使 FastAPI 應用程式崩潰了，任務訊息依然完好無損地存放在 Broker 中。

3. 消費者 (Consumer / Worker)

   • 這是一個或多個獨立運行的背景程式。它們的唯一工作就是不斷地去 Broker 那裡檢查「有沒有新的任務？」，一旦發現有，就把它取出來，兢兢業業地執行。

(圖片來源)

這個架構帶來了巨大的好處：

• 高可靠性：任務被持久化在 Broker 中，不怕遺失。專業的任務佇列框架還支援失敗重試機制。
• 高擴展性：當任務量暴增時，我們只需要增加更多的 Worker（消費者）即可，而無需改動 FastAPI 應用（生產者）。你可以輕易地將 Worker 部署在數十台甚至上百台機器上。
• 應用解耦：Web 伺服器和背景任務處理系統各自獨立，可以分開部署、升級和擴展，極大地提高了系統的健壯性和靈活性。

Celery 登場

在 Python 生態中，Celery 就是實現上述架構最知名、功能也最全面的分散式任務佇列框架。它扮演了生產者端的 Client 和消費者端的 Worker 角色，並能與 Redis 或 RabbitMQ 等 Broker 無縫協作。

小結

從 BackgroundTasks 到 Thread Pool，再到今天介紹的任務佇列，我們可以清楚地看到任務管理方案的演進軌跡：

• BackgroundTasks：適合輕量級、非關鍵性的即發即棄任務
• Thread Pool：解決了同步阻塞問題，但任務仍與應用程式生命週期綁定
• 任務佇列：提供企業級的可靠性、擴展性和系統解耦能力

任務佇列的核心價值在於將「任務發布」與「任務執行」徹底分離。透過 Producer、Broker、Consumer 三角架構，我們得到了一個既強壯又靈活的分散式任務處理系統。當你的應用面臨高負載、需要容錯機制、或者想要水平擴展背景任務處理能力時，任務佇列就是非常值得考慮的選擇。

在了解了「為什麼」需要任務佇列之後，下一篇文章，我們將親自動手，將 Celery 與 Redis 整合進我們的 FastAPI 專案中。