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

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

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

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

• 從基本功能說起
• 對比系統(tǒng)角色
• 本質區(qū)別
• 總結

1、從基本功能說起

什么是消息隊列？

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

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

什么是任務調度系統(tǒng)？

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

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

什么是任務隊列？

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

它解決的問題是比較經(jīng)典的，在線業(yè)務如何 實時 處理 長耗時 任務。

任務隊列通過封裝 異步任務發(fā)送、任務處理、任務狀態(tài)存儲、異常處理 等環(huán)節(jié)，提供了一套完整的處理長耗時任務的編程框架，實現(xiàn)了 隔離性、容錯性 的應用架構。

2、對比系統(tǒng)角色

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

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

先看下消息隊列的系統(tǒng)角色。

主要包括：

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

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

主要包括4類角色：

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

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

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

（2）任務隊列 VS 任務調度系統(tǒng)

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

我們以XXL-JOB為例，來看下系統(tǒng)角色。

包括2個角色：

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

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

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

3、本質區(qū)別

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

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

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

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

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

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

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

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

4、總結

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

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

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

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

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

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

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