拆解一下消息队列、任务队列、任务调度系统

,最近调研了下任务调度系统中间件，包括xxl-job、elastic-job等，发现跟任务队列有一些类似的能力，比如通过API（事件）触发任务执行。,随即想到，能否用任务调度系统覆盖任务队列的场景呢？,另外，一直以来，很多同学也经常会产生困惑，任务队列和消息队列究竟有什么区别？,因此，本文通过多个维度来进行拆解，试着分析 任务队列、消息队列、任务调度系统 这三类中间件 究竟有哪些不同，究竟谁更适合什么场景。,消息队列大家基本是耳熟能详，不管是经典的kafka、rocketmq，还是新兴的pulsar。
虽然它们在架构上都有所区别，但是本质上都是一种 应用 对 应用的 「通信方式」。,应用程序通过读写出入队列的「消息」来通信，而无需点对点直接连接应用。主要解决应用耦合、异步消息、流量削峰等问题，用来实现高性能，高可用，可伸缩和最终一致性架构。,任务调度系统也是大家比较熟悉的，从quartz到xxl-job，到elastic-job。主要解决的问题是，解决分布式场景下的 离线任务、定时任务 的调度问题，具备高可用、可视化、可运维、低延时等能力。,一些复杂场景，可能还需要进行任务编排（DAG)执行。,任务队列可能听过的人会少一点，没有特别出名的java开源框架，相对活跃一点的包括Celery、Resque等。,它解决的问题是比较经典的，在线业务如何 实时 处理 长耗时 任务。,任务队列通过封装 异步任务发送、任务处理、任务状态存储、异常处理 等环节，提供了一套完整的处理长耗时任务的编程框架，实现了 隔离性、容错性 的应用架构。,认识一个系统，除了通过文字简单了解基本功能外，最直接的方式是看看整体系统架构的角色。,先看下消息队列的系统角色。,,主要包括：,然后，我们看看任务队列的系统角色包括哪些。,,主要包括4类角色：,通过系统角色对比，我们可以看到，消息队列是任务队列的其中一个角色，任务队列中queue的选型可以是消息队列kafka、rocketmq，甚至可以是能提供类似能力的redis。,除了queue之外，任务队列的一个显著特点是，一般还需要一个storage系统角色来持久化任务的状态。,任务调度系统比较有代表性的开源产品包括Quartz、Elastic-job、XXL-JOB。,我们以XXL-JOB为例，来看下系统角色。,,包括2个角色：,从这里能看出，XXL-JOB是一个典型的「中心化」系统，任务都是根据预设规则从 调度中心 发起，然后由执行器来执行。当然，Elastic-job中的ElasticJob-lite也有「去中心化」方案，但是从逻辑模型的角度来说，仍然是一个需要调度中心进行调度的。,而任务队列的整个模型就是一个「去中心化」、「应用 对 应用 生产消费」系统，任务由producer发起，由consumer消费。,结合前面的基本功能和系统角色，我们可以更好地体会三个中间件的本质区别。,消息队列 本质上都是一种 应用 对 应用 的 「通信方式」，主要解决应用耦合、异步消息、流量削锋等问题。,任务队列 本质上是一种封装好的 应用 对 应用 异步任务 「编程框架」，它封装了对异步任务的如何重试、如何消费、如何获取任务结果、如何监控任务的运行情况 等等问题，让业务开发只关心业务逻辑。,同时，任务队列也是一种典型的 「架构风格」，这个编程框架 指导 业务开发对 长耗时 任务从普通 在线业务 的服务中拆分出来，避免影响在线业务的稳定性。因此，任务队列的主要应用场景也是 在线业务。,任务调度系统 设计之初就是为了解决分布式场景下的 离线任务、定时任务 的调度问题，它的设计目标是 轻量级、可视化、易扩展。,因此，它的设计没有 应用 对 应用 的生产消费概念，也不具备对高流量的承受能力（削峰）。,当然，任务调度系统 跟 任务队列 最大的区别，它不具备将 长耗时 任务从普通 在线业务 的服务中拆分出来的这种架构思想指导（大部分定时任务都是在夜间执行）。,任务调度系统的定位还是应用于 轻量级、离线业务 场景最为合适。,回过头看看一开始的两个问题。,不能。任务调度系统适用于 轻量级、离线业务 场景下的 定时任务 和 离线任务，使用调度/执行模式，不具备承接在线业务高流量的能力。,而任务队列适用于 在线业务 场景下的 长耗时任务，使用 生产消费模式，具备对高流量的承受能力（削峰）。并且指导业务开发将 长耗时 任务从普通 在线业务 的服务中拆分出来的架构思想。,任务队列是一个封装好的 异步任务编程框架，也是一种 长耗时任务 与 普通在线业务 拆分的架构思想。消息队列只是任务队列中的一个系统角色。,总结一下，其实三者的差异还是非常大的。,