拆解一下任務隊列、消息隊列、任務調度系統
最近調研了下任務調度系統中間件，包括xxl-job、elastic-job等，發現跟任務隊列有一些類似的能力，比如通過API（事件）觸發任務執行。
隨即想到，能否用任務調度系統覆蓋任務隊列的場景呢？
另外，一直以來，很多同學也經常會產生困惑，任務隊列和消息隊列究竟有什麼區別？
因此，本文通過多個維度來進行拆解，試著分析 任務隊列、消息隊列、任務調度系統 這三類中間件 究竟有哪些不同，究竟誰更適合什麼場景。
- 從基本功能說起
- 對比系統角色
- 本質區別
- 總結
1、從基本功能說起
什麼是消息隊列？
消息隊列大家基本是耳熟能詳，不管是經典的kafka、rocketmq，還是新興的pulsar。
雖然它們在架構上都有所區別，但是本質上都是一種 應用 對 應用的 「通訊方式」。
應用程式通過讀寫出入隊列的「消息」來通訊，而無需點對點直接連接應用。主要解決應用耦合、非同步消息、流量削鋒等問題，用來實現高性能，高可用，可伸縮和最終一致性架構。
什麼是任務調度系統？
任務調度系統也是大家比較熟悉的，從quartz到xxl-job，到elastic-job。
主要解決的問題是，解決分散式場景下的 離線任務、定時任務 的調度問題，具備高可用、可視化、可運維、低延時等能力。
一些複雜場景，可能還需要進行任務編排（DAG)執行。
什麼是任務隊列？
任務隊列可能聽過的人會少一點，沒有特別出名的java開源框架，相對活躍一點的包括Celery、Resque等。
它解決的問題是比較經典的，在線業務如何 實時 處理 長耗時 任務。
任務隊列通過封裝 非同步任務發送、任務處理、任務狀態存儲、異常處理 等環節，提供了一套完整的處理長耗時任務的編程框架，實現了 隔離性、容錯性 的應用架構。
2、對比系統角色
2.1 任務隊列 VS 消息隊列
認識一個系統，除了通過文字簡單了解基本功能外，最直接的方式是看看整體系統架構的角色。
先看下消息隊列的系統角色。
主要包括：
- 生產者 Producer
發布消息的角色。Producer通過 MQ 的負載均衡模組選擇相應的 Broker 集群隊列進行消息投遞，投遞的過程支援快速失敗和重試。 - 消費者 Consumer
消息消費的角色。 - 代理伺服器 Broker
Broker主要負責消息的存儲、投遞和查詢以及服務高可用保證。
然後，我們看看任務隊列的系統角色包括哪些。
主要包括4類角色：
- 任務生產者 Producer
發布任務的角色。Producer通過 MQ 的負載均衡模組選擇相應的 Broker 集群隊列進行消息投遞，投遞的過程支援快速失敗和重試。 - 消費者 Consumer
消費任務的角色。 - 隊列queue
Broker主要負責任務的存儲、投遞和查詢以及服務高可用保證。 - 任務狀態持久化storage
storage主要負責任務的狀態持久化、查詢等能力。可以選擇獨立的DB，也可以直接復用queue。
通過系統角色對比，我們可以看到，消息隊列是任務隊列的其中一個角色，任務隊列中queue的選型可以是消息隊列kafka、rocketmq，甚至可以是能提供類似能力的redis。
除了queue之外，任務隊列的一個顯著特點是，一般還需要一個storage系統角色來持久化任務的狀態。
2.2 任務隊列 VS 任務調度系統
任務調度系統比較有代表性的開源產品包括Quartz、Elastic-job、XXL-JOB。
我們以XXL-JOB為例，來看下系統角色。
包括2個角色：
- 調度模組（調度中心）：
負責管理調度資訊，按照調度配置發出調度請求，自身不承擔業務程式碼。調度系統與任務解耦，提高了系統可用性和穩定性，同時調度系統性能不再受限於任務模組； - 執行模組（執行器）：
負責接收調度請求並執行任務邏輯。任務模組專註於任務的執行等操作，開發和維護更加簡單和高效。接收「調度中心」的執行請求、終止請求和日誌請求等。
從這裡能看出，XXL-JOB是一個典型的「中心化」系統，任務都是根據預設規則從 調度中心 發起，然後由執行器來執行。當然，Elastic-job中的ElasticJob-lite也有「去中心化」方案，但是從邏輯模型的角度來說，仍然是一個需要調度中心進行調度的。
而任務隊列的整個模型就是一個「去中心化」、「應用 對 應用 生產消費」系統，任務由producer發起，由consumer消費。
3、本質區別
結合前面的基本功能和系統角色，我們可以更好地體會三個中間件的本質區別。
消息隊列本質上都是一種 應用 對 應用 的 「通訊方式」，主要解決應用耦合、非同步消息、流量削鋒等問題。
任務隊列本質上是一種封裝好的 應用 對 應用 非同步任務 「編程框架」，它封裝了對非同步任務的如何重試、如何消費、如何獲取任務結果、如何監控任務的運行情況 等等問題，讓業務開發只關心業務邏輯。
同時，任務隊列也是一種典型的 「架構風格」，這個編程框架 指導 業務開發對 長耗時 任務從普通 在線業務 的服務中拆分出來，避免影響在線業務的穩定性。因此，任務隊列的主要應用場景也是 在線業務。
任務調度系統設計之初就是為了解決分散式場景下的 離線任務、定時任務 的調度問題，它的設計目標是 輕量級、可視化、易擴展。
因此，它的設計沒有 應用 對 應用 的生產消費概念，也不具備對高流量的承受能力（削峰）。
當然，它跟任務隊列最大的區別，它不具備將 長耗時 任務從普通 在線業務 的服務中拆分出來的這種架構思想指導（大部分定時任務都是在夜間執行）。
任務調度系統的定位還是應用於 輕量級、離線業務 場景最為合適。
4、總結
回過頭看看一開始的兩個問題。
1）能否用任務調度系統覆蓋任務隊列的場景呢？
不能。任務調度系統適用於 輕量級、離線業務 場景下的 定時任務 和 離線任務，使用調度/執行模式，不具備承接在線業務高流量的能力。而任務隊列適用於 在線業務 場景下的 長耗時任務，使用 生產消費模式，具備對高流量的承受能力（削峰）。
2）任務隊列和消息隊列究竟有什麼區別？
任務隊列是一個封裝好的 非同步任務編程框架，也是一種 長耗時任務 與 普通在線業務 拆分的架構思想。消息隊列只是任務隊列中的一個系統角色。
總結一下，其實三者的差異還是非常大的。
希望能夠拋磚引玉，提供一些啟發和思考。如果你有其他補充和建議，歡迎留言討論。
都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜索「阿丸筆記 」第一時間閱讀，回復【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回復【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）
