流量消峰。比如在一个系统的高峰期，很多订单同时过来，可能超出了系统下游的处理能力，此时可以利用消息队列做缓冲，把一秒内下的订单分散成一段时间来处理
应用解藕。以电商应用为例，应用中有订单系统、库存系统、支付系统。用户创建订单后，如果耦合调用这些子系统，任何一个子系统出现了故障，都会造成下单操作异常；当转变成消息队列的方式后，系统间调用的问题会减少很多，比如物流系统出现了故障，需要几分钟来进行修复，这几分钟的时间内，物流系统要处理的消息被缓存在消息队列中，不影响其他子系统的使用，提升系统的可用性。
异步处理。比如两个服务A和B，B服务需要花费很长时间执行，但是A需要知道B什么时候可以执行完，以前一般有两种方式，一种是A过一段时间去调用B的查询api查询。或者A提供一个callback api，B执行完之后调用api通知A服务。现在有一种更好的方式，使用消息总线，A调用B服务后，只需要监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ，MQ会将此消息转发给A服务，这样A服务能够及时地得到异步处理成功的消息。

1.2 RabbitMQ

1.2.1 概念

RabbitMQ是一个消息中间件：它接受并转发消息，接收、存储和转发消息数据。

1.2.2 四大核心概念

生产者：产生数据发送消息的程序。
交换机：是RabbitMQ非常重要的一个部件，一方面它接收来自生产者的消息，另一方面它将消息推送到队列中，交换机必须确切知道如何处理它接收到的消息(处理逻辑)。
队列：队列是RabbitMQ内部使用的一种数据结构，尽管消息流经RabbitMQ和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。
消费者：大多时候是一个等待接收消息的程序。注意消费者和消费中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又可以是消费者。

1.2.3 RabbitMQ核心部分

1.2.4 名词介绍

Broker：接收和分发消息的应用，消息实体、MQ服务器。RabbitMQ Server就是Message Broker。
Virtual host：出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ Server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange/queue等。一个Broker内有多个vhost，每个vhost内又有多个交换机。
Connection：publisher/consumer和broker之间的TCP连接。
Channel：如果每一次访问RabbitMQ都建立一个连接，在消息量大的时候建立TCP连接的开销是巨大的，效率也低。Channel是在connection内部建立的逻辑连接，Channel作为轻量级的connection极大减少了操作系统建立TCP连接的开销。Channel之间是完全隔离的。
Exchange：message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型：
- direct：point-to-point
- topic：publish-subscribe
- fanout：multicast
Queue：消息最终被送到这里等待consumer取走。
Binding：exchange和queue之间的虚拟连接(绑定)，binding中可以包含routing key，Binding信息被存储到exchange中的查询表中，用于message的分发依据。

2. Work Queues工作模式

工作队列的主要思想是避免立即执行资源密集型任务，我们把任务封装为消息并将其发送到队列，在后台运行的工作进程将弹出任务并最终执行任务。当有多个工作线程(即消费者)时，这些工作线程将一起处理这些任务。

注意：处于同一队列的工作线程之间是竞争关系，同一个消息不能被重复消费。

2.1 轮询发送消息

消费者按照顺序有序地一个接收一次消息。

2.2 消息应答

2.2.1 概念

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它就挂掉了，会发生什么情况。RabbitMQ一旦向消费者传递了一条消息，便立即将该消息标记为删除。为了保证消息在发送过程中不丢失，RabbitMQ引入消息应答机制，即消费者在接收到消息并且处理该消息之后，告诉RabbitMQ它已经处理了，RabbitMQ可以把该消息删除了。

2.2.2 自动应答

消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡，因为这种模式如果消息在接收之前，消费者那边出现连接或者channel关闭，那么消息就丢失了；另一方面这种模式生产者那边可以传递过载的消息，没有对传递的消息数量进行限制，有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽。这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

2.2.3 消息应答的方法

Channel.basicAck(用于肯定确认)
- RabbitMQ已知道该消息被接收并且成功的处理消息࿰

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小桥流水78/article/detail/907634