简介
MQ（message queue）消息队列，也叫消息中间件。消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。它是类似于数据库一样需要独立部署在服务器上的一种应用，提供接口给其他系统调用。
消息队列
1、消息Message
网络中两台计算机或者两个通讯设备之间传递的数据。例如说：文本、音乐、视频等内容。
2、队列Queue
一种特殊的线性表（数据元素首尾相接），特殊之处在于只允许在首部删除元素和在尾部追加元素（FIFO）。入队、出队。
3、消息队列MQ
消息+队列，保存消息的队列。消息的传输过程中的容器；主要提供生产、消息接口供外部屌用数据的存储和获取。
为什么要使用消息中间件
具体的说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担，中间件带给应用新系统的，不只是开发的简便，开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入。
1）系统解耦
假设你有个系统A，这个系统A会产出一个核心数据，现在下游有系统B和系统C需要这个数据。那简单，系统A就是直接调用系统B和系统C的接口发送数据给他们就好了。
整个过程，如下图所示：
但是现在要是来了系统D、系统E、系统F、系统G，等等，十来个其他系统慢慢的都需要这份核心数据呢？如下图所示：
大家可别以为这是开玩笑，一个大规模系统，往往会拆分为几十个甚至上百个子系统，每个子系统又对应N多个服务，这些系统与系统之间有着错综复杂的关系网络。如果某个系统产出一份核心数据，可能下游无数的其他系统都需要这份数据来实现各种业务逻辑。此时如果你要是采取上面那种模式来设计系统架构，那么绝对你负责系统A的同学要被烦死了。先是来一个人找他要求发送数据给一个新的系统H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。一会那个系统B是个陈旧老系统要下线了，告诉系统A的同学：别给我发送数据了，接着系统A再次修改代码不再给这个系统B。
然后如果要是某个下游系统突然宕机了呢？
系统A的调用代码里是不是会抛异常？那系统A的同学会收到报警说异常了，结果他还要去care是下游哪个系统宕机了。所以在实际的系统架构设计中，如果全部采取这种系统耦合的方式，在某些场景下绝对是不合适的，系统耦合度太严重。并且互相耦合起来并不是核心链路的调用，而是一些非核心的场景（比如上述的数据消费）导致了系统耦合，这样会严重的影响上下游系统的开发和维护效率。因此在上述系统架构中，就可以采用MQ中间件来实现系统解耦。系统A就把自己的一份核心数据发到MQ里，下游哪个系统感兴趣自己去消费即可，不需要了就取消数据的消费，如下图所示：
2）异步调用
假设你有一个系统调用链路，是系统A调用系统B，一般耗时20ms；系统B调用系统C，一般耗时200ms；系统C调用系统D，一般耗时2s，如下图所示。
现在最大的问题就是：用户一个请求过来巨慢无比，因为走完一个链路，需要耗费：20ms + 200ms + 2000ms（2s） = 2220ms，也就是2秒多的时间。但是实际上，链路中的系统A调用系统B，系统B调用系统C，这两个步骤起来也就220ms。就因为引入了系统C调用系统D这个步骤，导致最终链路执行时间是2秒多，直接将链路调用性能降低了10倍，这就是导致链路执行过慢的罪魁祸首。
那此时我们可以思考一下，是不是可以将系统D从链路中抽离出去做成异步调用呢？其实很多的业务场景是可以允许异步调用的。举个例子：你平时点个外卖，咔嚓一下子下订单然后付款了，此时账户扣款、创建订单、通知商家给你准备菜品。接着，是不是需要找个骑手给你送餐？那这个找骑手的过程，是需要一套复杂算法来实现调度的，比较耗时。但是其实稍微晚个几十秒完成骑手的调度都是ok的，因为实际并不需要在你支付的一瞬间立马给你找好骑手，也没那个必要。那么我们是不是就可以把找骑手给你送餐的这个步骤从链路中抽离出去，做成异步化的，哪怕延迟个几十秒，但是只要在一定时间范围内给你找到一个骑手去送餐就可以了。这样是不是就可以让你下订单点外卖的速度变得超快？支付成功之后，直接创建好订单、账户扣款、通知商家立马给你准备做菜就ok了，这个过程可能就几百毫秒。然后后台异步化的耗费可能几十秒通过调度算法给你找到一个骑手去送餐，但是这个步骤不影响我们快速下订单。当然我们不是说那些大家熟悉的外卖平台的技术架构就一定是这么实现的，只不过是用一个生活中常见的例子给大家举例说明而已。所以上面的链路也是同理，如果业务流程支持异步化的话，是不是就可以考虑把系统C对系统D的调用抽离出去做成异步化的，不要放在链路中同步依次调用。这样，实现思路就是系统A -> 系统B -> 系统C，直接就耗费220ms后直接成功了。然后系统C就是发送个消息到MQ中间件里，由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。
3）流量削峰
假设你有一个系统，平时正常的时候每秒可能就几百个请求，系统部署在8核16G的机器的上，正常处理都是ok的，每秒几百请求是可以轻松抗住的。但是如下图所示，在高峰期一下子来了每秒钟几千请求，瞬时出现了流量高峰，此时你的选择是要搞10台机器，抗住每秒几千请求的瞬时高峰吗？
那如果瞬时高峰每天就那么半个小时，接着直接就降低为了每秒就几百请求，如果你线上部署了很多台机器，那么每台机器就处理每秒几十个请求就可以了，这不是有点浪费机器资源吗？大部分时候，每秒几百请求，一台机器就足够了，但是为了抗那每天瞬时的高峰，硬是部署了10台机器，每天就那半个小时有用，别的时候都是浪费资源的。
但是如果你就部署一台机器，那会导致瞬时高峰时，一下子压垮你的系统，因为绝对无法抗住每秒几千的请求高峰。此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。等高峰期过了，再消费一段时间，MQ里积压的数据就消费完毕了。
这个就是很典型的一个MQ的用法，用有限的机器资源承载高并发请求，如果业务场景允许异步削峰，高峰期积压一些请求在MQ里，然后高峰期过了，后台系统在一定时间内消费完毕不再积压的话，那就很适合用这种技术方案。
JMS规范
消息中间件是遵守JMS（java message service）规范的一种软件（大多数消息中间件遵守JMS规范）。要使用Java消息服务，你必须要有一个JMS提供者，管理会话和队列。现在既有开源的提供者也有专有的提供者。开源的提供者包括：Apache ActiveMQ、Kafka、WebMethods、阿里的RocketMQ等。
专业术语
提供者：实现JMS规范的中间件服务器。
客户端：发送或者接受消息的应用程序。
生产者：创建并发送消息的客户端。
消费者：接受并处理消息的客户端。
消息：应用程序之间传递的内容。
队列：一个容纳那些被发送的等待阅读的消息的区域，一旦消息被消费，将被从队列中移走。
主题 ：一种支持发送消息给多个订阅者的机制。
消息模式：在客户端之间传递消息的方式，JSM中定义了点对点模式（发送者、接收者）和发布订阅模式（发布者、订阅者）。
消息模式
点对点模式：Point-to-Point(P2P)
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。一般基于Pull或者Polling接收数据。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
每个消息只有一个消费者。一旦被消费，消息就不再在消息队列中。
提供者和消费者之间在时间上没有依赖性。当提供者发送了消息之后，不管消费者有没有正在运行，它不会影响到消息被发送到队列。
每条消息仅会传送给一个消费者。可能会有多个消费者在一个队列中侦听，但是每个队列中的消息只能被队列中的一个消费者所消费。
消息存在先后顺序。一个队列会按照消息服务器将消息放入队列中的顺序，把它们传送给消费者。当已被消费时，就会从队列头部将它们删除（除非使用了消息优先级）。
消费者在成功接收消息之后需向队列应答成功。
queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
发布订阅模式：Publish/Subscribe(Pub/Sub)
1、每个消息可以有多个消费者。
2、发布者和订阅者之间有时间上的依赖性。针对某个主题的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态。
3、为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。
4、每条消息都会传送给称为订阅者的多个消息消费者。订阅者有许多类型，包括持久型、非持久型和动态型。
5、发布者通常不会知道哪一个订阅者正在接收主题消息。
6、消息被推送给消费者。这意味着消息会传送给消费者，而无须请求。
topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝。
P2P和发布订阅的比较
1、共同点：消息生产者生产消息发送到queue中，然后消息消费者从queue中读取并且消费消息。
2、不同点：
P2P模型包括：消息队列（queue）、发送者（Sender）、接收者（Receive）
一个生产者生产的消息只有一个消费者（Consumer）(即一旦被消费，消息就不在消息队列中，比如说打电话)。
Pub/Sub包括：消息队列（queue）、主题（Topic）、发布者（Publisher）、订阅者（Subscriber）。
每个消息可以有多个消费者，彼此互不影响。比如我发布一个微博：关注我的人都能够看到。
消息消费方式
同步
订阅者或消费者调用receive方法来接收消息，receive方法在能够接收到消息之前（或超时之前）将一直阻塞。
异步订阅者或消费者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。
JMS规范接口
ConnectionFactor接口(连接工厂)
用于创建连接到消息中间件的连接工厂。创建Connection对象的工厂，根据消息类型的不同，用户将使用队列连接工厂QueueConnectionFactory或者主题连接工厂TopicConnectionFactory两种。可以通过JNDI来查找ConnectionFactory对象。
Connection接口(连接)
Connection表示在客户端和JMS系统之间建立的链接（对TCP/IP socket的包装），代表了应用程序和消息服务器之间的通信链路。Connection可以产生一个或多个Session。跟ConnectionFactory一样，Connection也有两种类型：QueueConnection和TopicConnection。
Destination接口(目标)
Destination是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。
它是消息生产者的消息发送目标或者说消息消费者的消息来源。
对于消息生产者来说，它的Destination是某个队列（Queue）或某个主题（Topic）;
对于消息消费者来说，它的Destination也是某个队列或主题（即消息来源）。
所以，Destination实际上就是两种类型的对象：Queue、Topic可以通过JNDI来查找Destination。
Session接口(会话)
Session是我们操作消息的接口。表示一个单线程的上下文，用于发送和接收消息。
由于会话是单线程的，所以消息是连续的，就是说消息是按照发送的顺序一个一个接收的。可以通过session创建生产者、消费者、消息等。Session提供了事务的功能。当我们需要使用session发送/接收多个消息时，可以将这些发送/接收动作放到一个事务中。同样，也分QueueSession和TopicSession。
MessageProducer接口(消息生产者)
消息生产者由Session创建，并用于将消息发送到Destination。消费者可以同步地（阻塞模式），或异步（非阻塞）接收队列和主题类型的消息。
同样，消息生产者分两种类型：QueueSender和TopicPublisher。可以调用消息生产者的方法（send或publish方法）发送消息。
MessageConsumer接口(消息消费者)
消息消费者由Session创建，用于接收被发送到Destination的消息。两种类型：QueueReceiver和TopicSubscriber。
可分别通过session的createReceiver(Queue)或createSubscriber(Topic)来创建，也可以session的creatDurableSubscriber方法来创建持久化的订阅者。
Message接口(消息)
是在消费者和生产者之间传送的对象，也就是说从一个应用程序创送到另一个应用程序。一个消息有三个主要部分。
消息头（必须）：包含用于识别和为消息寻找路由的操作设置。
一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容。可以创建定制的字段和过滤器（消息选择器）。
一个消息体（可选）：允许用户创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。消息接口非常灵活，并提供了许多方式
消息接口非常灵活，并提供了许多方式来定制消息的内容。
MessageListener(监听器)
消息监听器，如果注册了消息监听器，一旦消息到达，将自动调用监听器的onMessage方法。
EJB中的MDB（Message-Driven Bean）就是一种MessageListener。
消息中间件作用
1.系统解耦
系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。
2.异步通信
消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
对于一些非必须及时处理的业务，通过消息队列可以优化系统响应时间。提升系统性能。
3.流量削峰
使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
4.数据采集
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
5.可恢复性
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。
许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
6.可扩展性
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
7.顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
8、冗余
部分消息系统具有消息持久化能力，可规避消息处理前丢失的风险。
主流消息中间件
ActiveMQ
1、非常成熟，功能比较完备，大量公司使用；
2、社区越来越不活跃，维护越来越少，几个月才发一次版；
3、偶尔会有较低概率丢失消息；
4、多数使用目的主要是用于解耦和异步通信，较少在大规模吞吐的场景中使用。
RabbitMQ
1、比较成熟，功能比较完备，大量公司使用；
2、Erlang语言开发，性能极其好，延时很低；
3、比较好用，社区活跃，几乎每个月都发布几个版本；
4、吞吐量万级，和其他相比会略低一些，这是因为他做的实现机制比较重；
5、Erlang开发，语言难度大，很难读源码，很难定制和掌控。基本只能依赖于开源社区的快速维护和修复bug。
6、集群动态扩展会很麻烦，这主要是erlang语言本身带来的问题。
7、支持多协议AMQP、XMPP、SMTP、STOMP，支持负载均衡，数据持久化。同时支持Peer-to-Peer和发布/订阅模式。
RocketMQ
1、文档相对来说简单一些，接口简单易用（接口不是按照标准JMS规范）；
2、阿里大规模应用，有保障（阿里日处理消息上百亿之多），可以做到大规模吞吐，性能也非常好；
3、分布式扩展也很方便；
4、社区比较活跃，维护还可以；
5、可靠性和可用性都不错；
6、支撑大规模的topic数量；
7、支持复杂MQ业务场景；
8、Java语言编写，我们可以自己阅读源码。
Kafka
1、仅提供较少的核心功能；
2、提供超高的吞吐量；
3、ms级的延迟；
4、极高的可用性以及可靠性；
5、分布式可以任意扩展；
6、一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用；
7、topic的大幅增加会导致吞吐量的大幅度下降；所以尽量保证topic数量不要过多，以保证其超高吞吐量。如果要支撑大规模topic，需要增加更多的机器资源
8、消息有可能重复消费；
9、天然适合大数据实时计算以及日志收集，在大数据领域中以及日志采集得以广泛使用。
————————————————
版权声明：本文为CSDN博主「骑个小蜗牛」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/JokerLJG/article/details/122981819