rabbitmq的作用：
（1）接口限流：当前端产生高并发请求时，并不会像“无头苍蝇”一样立即到达后端系统接口，而是像每天上班时的地铁限流一样，将这些请求按照先来后到的规则加入RabbitMQ的队列，即在某种程度上实现“接口限流”。

（2）消息异步分发：当商品库存充足时，当前抢购的用户将可以抢到该商品，之后会异步地通过发送短信、发送邮件等方式通知用户抢购成功，并告知用户尽快付款，即在某种程度上实现了“消息异步分发”

在后续章节介绍 RabbitMQ的消息模型时，会发现“生产者+消息+交换机+路由对应队列+消费者”跟Spring的事件驱动模型出奇地相似。

举个例子，RabbitMQ就跟“邮局”很类似，寄过邮件的读者想必也知道一个邮局的核心要素主要包括邮件、邮寄箱子、寄邮件用户、收邮件用户和邮递员
图片说明

其中，投递邮件的用户A相当于RabbitMQ产生消息的生产者，邮件相当于消息，接收邮件的用户B相当于RabbitMQ接收处理消息的消费者，而邮件箱子和邮递员可以分别看作是RabbitMQ消息模型中的交换机和队列。接下来便简要介绍一下RabbitMQ在实际应用开发中涉及的这些核心基础组件。
● 生产者：用于产生、发送消息的程序。
● 消费者：用于监听、接收、消费和处理消息的程序。
● 消息：可以看作是实际的数据，如一串文字、一张图片和一篇文章等。在RabbitMQ底层系统架构中，消息是通过二进制的数据流进行传输的。
● 队列：消息的暂存区或者存储区，可以看作是一个“中转站”。消息经过这个“中转站”后，便将消息传输到消费者手中。
● 交换机：同样也可以看作是消息的中转站点，用于首次接收和分发消息，其中包括Headers、 Fanout、Direct和Topic这4种。
● 路由：相当于密钥、地址或者“第三者”，一般不单独使用，而是与交换机绑定在一起，将消息路由到指定的队列
图片说明

在RabbitMQ的核心组件体系中，主要有4种典型的消息模型，即
基于HeadersExchange的消息模型、
基于FanoutExchange的消息模型、
基于DirectExchange的消息模型、
基于TopicExchange的消息模型，
在实际生产环境中，应用最广泛的莫过于后3种消息模型

基于FanoutExchange的消息模型
FanoutExchange，顾名思义，是交换机的一种，具有“广播消息”的作用，即当消息进入交换机这个“中转站”时，交换机会检查哪个队列跟自己是绑定在一起的，找到相应的队列后，将消息传输到相应的绑定队列中，并最终由队列对应的消费者进行监听消费
图片说明

基于DirectExchange的消息模型
DirectExchange，顾名思义，也是RabbitMQ的一种交换机，具有“直连传输消息”的作用，即当消息进入交换机这个“中转站”时，交换机会检查哪个路由跟自己绑定在一起，并根据生产者发送消息指定的路由进行匹配，如果能找到对应的绑定模型，则将消息直接路由传输到指定的队列，最终由队列对应的消费者进行监听消费。
图片说明

基于TopicExchange的消息模型
TopicExchange消息模型同样是由交换机、路由和队列严格绑定构成，与前面介绍的另外两种消息模型相比，最大的不同之处在于其支持“通配式”的路由，即可以通过为路由的名称指定特定的通配符“”和“#”，从而绑定到不同的队列中。其中，通配符“”表示一个特定的“单词”，而通配符“#”则可以表示任意的单词（可以是一个，也可以是多个，也可以没有）。某种程度上讲“#”通配符表示的路由范围大于等于“”通配符表示的路由范围，即前者可以包含后者。如果说基于DirectExchange的消息模型在RabbitMQ诸多消息模型中属于“正规军”，那么基于TopicExchange的消息模型则可以号称是“王牌军”，可以“统治正规军”。而事实上也正是如此，这主要是因为其通配符起到的功效：当这种消息模型的路由名称包含“”时，由于“*”相当于一个单词，因而此时此种消息模型将降级为“基于DirectExchange的消息模型”；当路由名称包含“#”时，由于#相当于0个或者多个单词，因而此时此种消息模型将相当于“基于FanoutExchange的消息模型”，即此时绑定的路由将不起作用了，哪怕进行了绑定，也不再起作用！
图片说明

RabbitMQ确认消费机制
如何保证消息能够被准备消费、不重复消费，RabbitMQ则是提供了“消息确认机制”，即ACK模式。RabbitMQ的消息确认机制有3种，分别是NONE（无须确认）、AUTO（自动确认）和MANUAL（手动确认） ，不同的确认机制，其底层的执行逻辑和实际应用场景是不相同的

在实际生产环境中，为了提高消息的高可用、防止消息重复消费，一般都会使用消息的确认机制，只有当消息被确认消费后，消息才会从队列中被移除，这也是避免消息被重复消费的实现方式。如图所示5.44为RabbitMQ提供的3种确认消费机制所在的枚举类。

NONE指的是“无须确认”机制，即生产者将消息发送至队列，消费者监听到该消息时，无须发送任何反馈信息给RabbitMQ服务器。这就好比“用户禁止某个App应用的通知提醒”是一个道理，当App有重大更新信息时，虽然App后端会给用户异步推送消息，但是由于用户进行了相关设置，因而虽然消息已经发送出去了，但却迟迟得不到用户的“查看”或者“确认”等反馈信息，好像消息“石沉大海了一般”
图片说明

接着介绍 AUTO消费模式。顾名思义，AUTO指的是“自动确认”机制，即生产者将消息发送至队列，消费者监听到该消息时，需要发送一个 AUTO ACK的反馈信息给RabbitMQ服务器，之后该消息将在 RabbitMQ的队列中被移除。其中，这种发送反馈信息的行为是 RabbitMQ“自动触发”的，即其底层的实现逻辑是由 RabbitMQ内置的相关组件实现自动发送确认反馈信息。此种消息确认模式的流程如图5.46所示。
图片说明

最后介绍的是MANUAL消费模式。它是一种“人为手动确认消费”机制，即生产者将消息发送至队列，消费者监听到该消息时需要手动地“以代码的形式”发送一个ACK的反馈信息给RabbitMQ服务器，之后该消息将在RabbitMQ的队列中被移除，同时告知生产者，消息已经成功发送并且已经成功被消费者监听消费了。MANUAL消息确认模式的大概流程如图5.47所示。
图片说明

以上3种确认消费模式在实际生产环境中有不同的应用场景。其中，比较典型常见的当属基于AUTO和基于MANUAL机制的消费模式。由于NONE消费模式类似于“泼出去的水就收不回来”一样，发送完了之后就不需要再去理会了，因而此种模式严格来讲是不够严谨的，因此在实际业务场景中比较少见，笔者也建议读者尽量少用。