什么場景下會使用后臺任務？

常見的三類場景：

其一，密集任務處理。

舉例：用戶上傳頭像場景，上傳完原圖之后，需要生成大圖，中圖，小圖。這個過程非常占用磁盤IO，且比較耗時，不應該讓用戶在上傳頁面等待，故可以啟動一個后臺任務來執行。

其二，定期任務處理。

舉例：每天要清理日志，每周要備份數據庫，每月要統計銷售提成，每年要導出IT審計數據。這類每天，每周，每月，每年都定期執行的任務，可以啟動一個后臺任務來執行。

其三，批量任務處理。

舉例：要對所有數據進行一次性加密處理，要對大語言模型進行參數訓練，這類任務雖然不是定期執行，但也一般不啟動服務，而是使用后臺任務。

后臺任務有幾種常見的觸發模式？

常見的有2.5種：

• 第1種，時間表觸發（Schedule-driven triggers）。例如：crontable，基于計時器周期，定期觸發。
• 第2種，事件觸發（Event-driven triggers）。如前文的例子，用戶上傳原圖時，觸發大圖，中圖，小圖的生成。

畫外音：這里也可以啟動一個以分鐘為單位的crontable定期觸發來實現，但效率較低。

• 第2.5種，人工觸發（Manual-driven triggers）。老板找你導數據，你才執行任務，這也算事件觸發的一種特例。只不過發過來的消息不是MQ，而是老板命令。

架構設計過程中，后臺任務的設計重點是什么？

后臺任務方案設計上有三個重點：

(1) 其一，高可用。除了要考慮冗余+故障轉移之外，還要重點考慮任務的執行狀態與任務元數據的保存，同時要有任務探測與任務重試機制，以保證任務的高可用。這一部分，主要由分布式調度平臺來實現。

(2) 其二，冪等性。后臺任務中斷時，會不會污染數據；后臺任務重試時，如何保證重試任務的冪等性。這一部分，主要是由業務任務代碼來保證。

(3) 其三，數據傳遞。工程系統與后臺任務之間的數據如何傳遞，最佳實踐是：只傳遞消息元數據，不傳遞批量數據本身。

• 例子1：工程系統用戶上傳了原圖，只給后臺任務傳遞用戶uid和消息類型，不要把原圖當做參數。
• 例子2：生成報表的多個任務之間，只傳遞任務開始，任務結束等消息，不要把數據批量傳輸。

知其然，知其所以然。

思路比結論更重要。