| 应用场景 |
RabbitMQ以至于MQ的应用场景有4个：异步处理、应用解耦、流量削峰、日志处理。
异步处理
像10086，我们在app买票成功后，它会提示我们“购票成功”，然后过一会就会收到短信，提示你出票成功，座位号之类的。
又或者，当你在一个网站新注册后，这个网站会给你发邮件和短信，祝贺你注册成功。
有3种供选方案：
（1）串行方式
这种方式是最笨的，就是先写入数据库，然后发送邮件，最后发送短信，都成功以后，才会返回给用户“注册成功”
（2）并行方式
这种方式进行了优化，就是写入数据库后，同时发送邮件和短信，任务完成后，将结果返回给用户
（3）使用消息队列
我们可以想想，发送邮件和短信是必须的吗？不是。这种方式的流程是：先写入数据库，然后写入消息队列，最后将结果返还给用户。至于发送邮件和短信，可以在之后进行。这样，对于用户来说，等待的时候大大减少了。
应用解耦
场景引入：
用户下单后，订单系统需要通知库存系统减少库存。
供选方案：
（1）用户下单后，订单系统调用库存系统的接口，通知库存系统要减少库存。
（2）用户下单后，订单系统完成持久化处理后，将消息写入消息队列，返回用户订单下单成功。
库存系统订阅下单信息，采用拉/推的方式，获取下单信息后，进行库存操作。
比较：显然，第（2）种比第一种更先进，消解了订单系统和库存系统之间的耦合。
流量削峰
这一点我们在讲解Redis的博客中提到过。
在秒杀活动中，极短的时间内，有大量的请求涌入，如果都从数据库层面操作，就会让数据库瘫痪。
解决办法就是加入消息队列，这样就将请求“积压”在了消息队列中，数据库能尽可能多地调用就调，调用不了的可以先存着。
当然，消息队列也有满的时候，如果超过了容量，它就会直接抛弃用户请求或跳转到错误页面。
日志处理
日志处理和流量削峰的过程大致一样，解决的是大量日志传输的问题。Rabbitmq也能进行日志处理，但是我们一般使用Kafka进行日志处理。
| 在ITOO中的使用 |
在ITOO的教务模块的学生抢课中，使用了RabbitMQ技术。使用的是它的削峰功能，学生抢课的请求信息发送到RabbitMQ中，数据库的储存业务再调用，这实现了异步处理，提高了系统的性能。
不知读者是否有这个疑问：RabbitMQ怎么知道这个课程有几个名额，要是存储的请求超了容量可怎么办？
答：举个栗子吧，比如语文课程有40个名额，那抢课之前，已经将40这个容量数字通过Redis缓存到RabbitMQ中了，就相当于告诉了RabbitMQ，请求语文的最多只能是40个人。
当前40个人的请求进入到RabbitMQ后，系统返回学生“抢课成功”；如果第41个请求要求进入RabbitMQ，RabbitMQ会拒绝，并返回给用户“此课已满”。
| 同类比较 |
| 名字 | 适用场景 |
|---|---|
| RabbitMQ | 稳定性要求较高的企业 |
| ActiveMQ | 适合中小企业级消息应用场景，不适合上千个队列的应用场景 |
| Kafka | 大数据日志处理或对实时性和可靠性要求较低的场景 |
| rocketMQ | 适合大型企业 |
| Redis | 不推荐 |
| 小结 |
（一）
还有3个和RabbitMQ有联系的名词：
AMQP理论
这是一个协议，RabbitMQ遵循此协议。
ACK机制
每次消费者取出消息时会通知队列，我拿到了，当队列接收到这条消息，就会把消息删除，这是默认的ACK机制。如果在接收消息之后，消费者挂掉，或者任何情况没有返回ack，队列中这条消息将不会删除，可以一直存着，等待其他消费者来取。
Erlang
我们知道，安装Rabbitmq时，需要先下载安装Erlang。因为Rabbitmq是由Erlang语言编写的。
（二）
本篇博客是小编参考各种资料总结而成的RabbitMQ笔记，尤其是图片，大多都是直接拿来用的，感谢网上各种大神的分享！
本文参考的博客：
https://blog.csdn.net/qq_31812703/article/details/80668784
https://blog.csdn.net/qq_30764991/article/details/80239076
https://blog.csdn.net/qq_25911515/article/details/81464271