• 为什么需要，它能解决什么问题？

1异步：不等待

2解耦：任务的串行变并行

3流量削峰：大任务量负载均衡

• 消息中间件有哪些？

 rabbitMQ,kafka,flume

AMQP: advanced message queue protocol

• RabbitMQ的组成元素有哪些？

0 消息  分为消息头和消息体，消息头包含：路由键 routing-key,优先级priority,delivery-mode

1 生产者 producer 

2 broker 主机 可以有多个vhost

3 vhost 虚拟主机，可理解为一个小型的rabbitmq服务器，是一组交换机，队列，有相同的身份标识

4 交换机 exchange 用于区分type类型，（消息发布类型）将消息发送到不同的队列里

5 队列，queue 消息的载体 和交换机之间路由规则进行绑定，这里有一个设置binding-key

6 信道 消费者和队列间通信是通过tcp连接，但频繁连接性能差，就有了这个虚拟通道，它对应的是一个线程，更省资源

7 消费者

参考：https://www.jianshu.com/p/79ca08116d57

• 消息的发布模式有那些？

消息如何正确的发送到对应的队列中呢？

消息本身有一个routing-key的标识，队列和交换机之间也有一个binding-key的标识

1 direct发布订阅模式：routing-key=binding-key  完全匹配，单播

2 fanout广播模式： 交换机的类型是fanout,发到这个交换机上的消息，就直接转发到跟这个交换机关联的所有队列里

3topic主题模式：此时的binding-key是一个模式  ，例如 usa.#,而 routing-key是一个具体的值 如usa.news， 这样就建立了模糊规则匹配

4 headers模式：只是标识放在了消息头中，其他和direct相同

 

这里的绑定，就是把队列和交换机做了绑定，指定了binding-key

 

 

对于生产者，通过指定交换机，routing-key，就确定了消息被发送到何处，哪个队列中

对于消费者，通过指定队列，交换机，binding-key就确定了消息的来源，获取消息后，还有一步确认动作：

确认又分为： （ACK确认机制，消费者处理完消息后，通知mq，mq才将其从队列中删除）

  手动确认

  自动确认

注意：如果mq收不到确认反馈，会再次将消息放到队列里，重复发送，严重的话会内存泄漏

不论是生产者发送消息，还是消费者处理消息，都存在不确定性，意外失败的情况，如何又要可靠，又要性能，兼顾呢？

  1事务开启--提交/回滚,

  2 confirm确认

这两种方式都是对chnnel信息进行相应的设置，等待，完成 监听