最近調研了下任務調度系統中間件，包括xxl-job、elastic-job等，發現跟任務隊列有一些類似的能力，比如通過API（事件）觸發任務執行。

隨即想到，能否用任務調度系統覆蓋任務隊列的場景呢？

另外，一直以來，很多同學也經常會產生困惑，任務隊列和消息隊列究竟有什么區別？

因此，本文通過多個維度來進行拆解，試著分析 任務隊列、消息隊列、任務調度系統 這三類中間件 究竟有哪些不同，究竟誰更適合什么場景。

• 從基本功能說起
• 對比系統角色
• 本質區別
• 總結

1、從基本功能說起

什么是消息隊列？

消息隊列大家基本是耳熟能詳，不管是經典的kafka、rocketmq，還是新興的pulsar。
雖然它們在架構上都有所區別，但是本質上都是一種 應用 對 應用的 「通信方式」。

應用程序通過讀寫出入隊列的「消息」來通信，而無需點對點直接連接應用。主要解決應用耦合、異步消息、流量削峰等問題，用來實現高性能，高可用，可伸縮和最終一致性架構。

什么是任務調度系統？

任務調度系統也是大家比較熟悉的，從quartz到xxl-job，到elastic-job。主要解決的問題是，解決分布式場景下的 離線任務、定時任務 的調度問題，具備高可用、可視化、可運維、低延時等能力。

一些復雜場景，可能還需要進行任務編排（DAG)執行。

什么是任務隊列？

任務隊列可能聽過的人會少一點，沒有特別出名的java開源框架，相對活躍一點的包括Celery、Resque等。

它解決的問題是比較經典的，在線業務如何 實時 處理 長耗時 任務。

任務隊列通過封裝 異步任務發送、任務處理、任務狀態存儲、異常處理 等環節，提供了一套完整的處理長耗時任務的編程框架，實現了 隔離性、容錯性 的應用架構。

2、對比系統角色

（1）任務隊列 VS 消息隊列

認識一個系統，除了通過文字簡單了解基本功能外，最直接的方式是看看整體系統架構的角色。

先看下消息隊列的系統角色。

主要包括：

• 生產者 Producer發布消息的角色。Producer通過 MQ 的負載均衡模塊選擇相應的 Broker 集群隊列進行消息投遞，投遞的過程支持快速失敗和重試。
• 消費者 Consumer消息消費的角色。
• 代理服務器 BrokerBroker主要負責消息的存儲、投遞和查詢以及服務高可用保證。?

然后，我們看看任務隊列的系統角色包括哪些。

主要包括4類角色：

• ?任務生產者 Producer發布任務的角色。Producer通過 MQ 的負載均衡模塊選擇相應的 Broker 集群隊列進行消息投遞，投遞的過程支持快速失敗和重試。
• 消費者 Consumer消費任務的角色。
• 隊列queueBroker主要負責任務的存儲、投遞和查詢以及服務高可用保證。
• 任務狀態持久化storagestorage主要負責任務的狀態持久化、查詢等能力。可以選擇獨立的DB，也可以直接復用queue。?

通過系統角色對比，我們可以看到，消息隊列是任務隊列的其中一個角色，任務隊列中queue的選型可以是消息隊列kafka、rocketmq，甚至可以是能提供類似能力的redis。

除了queue之外，任務隊列的一個顯著特點是，一般還需要一個storage系統角色來持久化任務的狀態。

（2）任務隊列 VS 任務調度系統

任務調度系統比較有代表性的開源產品包括Quartz、Elastic-job、XXL-JOB。

我們以XXL-JOB為例，來看下系統角色。

包括2個角色：

• ?調度模塊（調度中心）：負責管理調度信息，按照調度配置發出調度請求，自身不承擔業務代碼。調度系統與任務解耦，提高了系統可用性和穩定性，同時調度系統性能不再受限于任務模塊。
• 執行模塊（執行器）：負責接收調度請求并執行任務邏輯。任務模塊專注于任務的執行等操作，開發和維護更加簡單和高效。接收“調度中心”的執行請求、終止請求和日志請求等。?

從這里能看出，XXL-JOB是一個典型的「中心化」系統，任務都是根據預設規則從 調度中心 發起，然后由執行器來執行。當然，Elastic-job中的ElasticJob-lite也有「去中心化」方案，但是從邏輯模型的角度來說，仍然是一個需要調度中心進行調度的。

而任務隊列的整個模型就是一個「去中心化」、「應用 對 應用 生產消費」系統，任務由producer發起，由consumer消費。

3、本質區別

結合前面的基本功能和系統角色，我們可以更好地體會三個中間件的本質區別。

消息隊列 本質上都是一種 應用 對 應用 的 「通信方式」，主要解決應用耦合、異步消息、流量削鋒等問題。

任務隊列 本質上是一種封裝好的 應用 對 應用 異步任務 「編程框架」，它封裝了對異步任務的如何重試、如何消費、如何獲取任務結果、如何監控任務的運行情況 等等問題，讓業務開發只關心業務邏輯。

同時，任務隊列也是一種典型的 「架構風格」，這個編程框架 指導 業務開發對 長耗時 任務從普通 在線業務 的服務中拆分出來，避免影響在線業務的穩定性。因此，任務隊列的主要應用場景也是 在線業務。

任務調度系統 設計之初就是為了解決分布式場景下的 離線任務、定時任務 的調度問題，它的設計目標是 輕量級、可視化、易擴展。

因此，它的設計沒有 應用 對 應用 的生產消費概念，也不具備對高流量的承受能力（削峰）。

當然，任務調度系統 跟 任務隊列 最大的區別，它不具備將 長耗時 任務從普通 在線業務 的服務中拆分出來的這種架構思想指導（大部分定時任務都是在夜間執行）。

任務調度系統的定位還是應用于 輕量級、離線業務 場景最為合適。

4、總結

回過頭看看一開始的兩個問題。

（1）能否用任務調度系統覆蓋任務隊列的場景呢？

不能。任務調度系統適用于 輕量級、離線業務 場景下的 定時任務 和 離線任務，使用調度/執行模式，不具備承接在線業務高流量的能力。

而任務隊列適用于 在線業務 場景下的 長耗時任務，使用 生產消費模式，具備對高流量的承受能力（削峰）。并且指導業務開發將 長耗時 任務從普通 在線業務 的服務中拆分出來的架構思想。

（2）任務隊列和消息隊列究竟有什么區別？

任務隊列是一個封裝好的 異步任務編程框架，也是一種 長耗時任務 與 普通在線業務 拆分的架構思想。消息隊列只是任務隊列中的一個系統角色。

總結一下，其實三者的差異還是非常大的。