随着用户流量的快速增长，由于传统应用在系统接口和服务处理层面仍然沿用高耦合和同步的处理模式，导致接口由于线程阻塞而延长了整体响应时间，即所谓的高延迟，为解决这个问题使用了rabbitMQ。
RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件,用于在分布式系统中存储转发消息,有良好的易用性，RabbitMQ既可以单点部署也可以多节点部署，某正程度上可以满足目前互联网对高并发、高可用的要求
知识网
| 原理解析 |
1.Brocker：消息队列服务器实体，Rabbitmq可以作为一个选择。
2.Exchange：消息交换机，用于接收、分配消息。指定消息按什么规则，路由到哪个队列。
3.Queue：消息队列，用于存储生产者的消息。每个消息都会被投入到一个或者多个队列里。
4.Binding Key：绑定关键字，用于把交换器的消息绑定到队列中，它的作用是把exchange和queue按照路由规则binding起来。
5.Routing Key：路由关键字，用于把生产者的数据分配到交换器上。exchange根据这个关键字进行消息投递。
6.Vhost：虚拟主机，一个broker里可以开设多个vhost，用作不用用户的权限分离。
7.Producer：消息生产者，就是投递消息的程序。
8.Consumer：消息消费者，就是接受消息的程序。
9.Channel：信道，消息推送使用的通道。可建立多个channel，每个channel代表一个会话任务。
核心基础组件
- 生产者：用于产生、发送消息的程序
- 消费者：用于监听、接收、消费和处理消息的程序
- 消息：可以看做是实际的数据，如一串文字，一个图片，一篇文章等，在rabbitMQ的底层架构中，消息是通过二进制的数据流进行传输的
- 队列：消息的暂存区或者存储区，可以看做是一个中间站，消息通过这个中转站之后，便将消息传输到消费者手中
- 交换机：同样可以看作消息的中转站点，用于首次接收和分发消息，其中包括Header、Fanout、Direct和Topic这4种
- 路由：相当于密钥、地址或者第三者，一般不单独使用，而是与交换机绑定在一起，将消息路由到指定队列
| 应用场景实例 |
1.日志处理
前端发送请求到后端接口，这样的操作会被记录在日志里面，然后会有专门的日志收集程序收集日志到rabbitMQ，然后rabbitMQ会将日志进行归档离线计算存入mysql，然后通过别的程序生成报表
或者消息中间件进行流计算
2.业务 异步
串行
传统的一个登录系统注册业务，注册花费50ms，然后会发送邮件和手机短信，这三个操作时串行化进行的，一共花费50+50+50=150ms
并行
并行是指注册需要50s，然后把发短信和发邮件并行处理，使用了50+50=100ms
异步
加入消息中间件之后，用户注册花了50ms，5ms发送到消息中间件，然后短信服务和邮件服务同时花50ms消费消息，一共花了55ms
3.应用解耦 分布式微服务
应用解耦是指传统的系统，订单系统直接调用库存耦合性太强，可以让库存系统生产产品，然后由订单系统去消费产品，这样就完成了解耦
4.流量削峰
假如有一个秒杀活动，有20000个人同时发请求，直接发到数据库，很容易就把数据库挂掉，这个时候可以通过消息中间件，将请求先存入消息中间件，然后再根据系统的承受能力来处理。
| 5种队列模型 |
官网解说： https://www.rabbitmq.com/getstarted.html
P：消息的生产者
红色：队列
C：消费者
3个对象 生产者 队列 消费者
1.简单队列
如何实现
生产者
- 获取连接
- 建立通道
- 创建队列
- 发布消息
- 关闭通道和连接
消费者
- 获取连接
- 创建通道
- 声明队列
- 调用handleDelivery（channel的相关方法去，接收消息）
- 监听队列
执行结果
生产者生产一个
消费者消费一个
简单队列的不足：
- 耦合性高，生产者对应消费者
- 如果想要多个消费者消费队列中消息，就不行了
- 队列名变更，这时候就得同时变更
2.工作队列-Work queues
如果想要多个消费者消费上面的消息，简单队列就无法完成任务了，这个时候就需要工作队列，
而且生产者生产消费耗时较少，而消费者需要跟业务结合，接收消息就需要处理，耗时较长。容易队列积压消息。
2.1 工作队列之轮询
代码：
生产者
接收者1
接收者2
运行结果
生产者生产了50个
接收者1，接收的都奇数位，共25条消息
接收者2：接收的都是偶数位消息，25个消息
结论：处在工作队列模式，消息队列采用轮询的方式给消费者发消息，虽然接收者1的消费速度慢，但是两个接收者最终消费的消息个数是一样的。
2.2 工作队列之公平分发
和轮询的代码相比只要增加几行代码即可
send.java
Recv1.java
Recv2.java和 Recv1.java的修改一样
执行结果
现象：可以看出Recv2的处理快，执行中Recv2也要先执行完
3.发布订阅
- 一个生产者，多个消费者
- 每个消费者都有自己的队列
- 生产者没有直接把消息发送到队列，而是发到了交换机
- 每个队列都要绑定到交换机上
- 生产者发送的消息，经过交换机到达队列，就能实现一个消息被多个消费者消费
实例
生产者Send.java
Recv1.java
Recv2.java
执行结果
Send发送一条消息
两个Recv都收到了
查看交换机绑定的队列
4.路由选择
路由模式特点：
- 队列与交换机的绑定，不能是任意绑定了，而是要指定一个Routingkey(路由key)
- 消息的发送方在向Exchange发送消息时，也必须指定消息的RoutingKey
- Exchange不再把消息交给每一个绑定的队列，而是根据消息的RoutingKey进行判断，只有队列的Routingkey完全一致才能收到消息
生产者
Recv1
Recv2
Recv2比Recv1多了一个routingkey insert
当生产者选择routingkey为insert时，之有Recv2能收到，update和delete则都可以收到消息
执行结果分析：
send执行了两次第一次是delete，第二次是insert
Recv1收到一次delete的消息
Recv2收到了两条消息
5.主题
6.RPC
如何使用rabbitMQ
- Override：整体一览。
- Connections：网络连接，比如一个 TCP 连接。
- Channels：信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的 TCP 连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
Exchanges：交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 - Queues：消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
1.添加用户
2.授权
然后就可以用user_mmr +密码登录了