RABBITMQ为什么要使用

1、问：为什么要使用rabbitMq呢？

面试官问这个问题，肯定是想知道你们公司有一个什么场景需要使用到这个Mq，这个场景有一个什么技术挑战导致必须要用这个mq，用了这个mq之后有什么好处。mq经典的使用场景有解耦，异步，削锋。

异步通信：当一个系统收到请求，需要在自己系统处理数据，处理完后，还需要把数据发送给其他系统。而每个系统接收请求后处理数据的时间不一致。如果是同步请求的话，需要等待所有请求处理完之后，才能将结果返回。而异步是非阻塞的，可以直接将结果返回，然后再去处理数据。用mq可以把这个同步通信的过程变成异步通信的流程，从而达到一个低延时的特性。

系统耦合：当一个项目中，有多个系统时会发生严重的耦合。当一个系统有一个很重要的基础数据，而其他系统也需要这些数据。如果其他系统挂掉了，还怎么将这些消息发送出去。这个时候我们可以将消息发送到mq上，如果其他系统需要这些基础数据，可以直接去mq里面消费就行，不需要关系系统有没有挂掉，或者超时的情况。这就是mq的一个发布消息订阅模型，可以降低系统的耦合度。

流量削锋：当系统在某一瞬间有五千个请求进来时，而我们系统最多能处理两千条请求。那我们可以从mq中处理系统所承受的最大限度的请求，等高峰期一过，就将在mq中积压的请求全部处理掉。

缺点：不过使用mq，会导致系统可用性降低，复杂度提高。系统本身的外部依赖越多越容易挂掉，如果系统好好地，但是mq划掉的，整个项目就用不了了。还有如果硬生生加进来一个mq，还要考虑怎么保证数据的一致性，如果一个系统处理完数据后结果返回成功了，但是系统其他系统有一个报错了，数据就会不一致。，有没有重复性消费，如果数据丢失了怎么办。

工作模型：

RabbitMQ 交换机类型

1、直连交换机（Direct Exchange）：当一个交换机绑定一个队列，再绑定一个routing key ,当发送消息时，指定一个bingding key,这样消息发送到交换机时，会被送到指定的队列里面去。是一种发布/订阅模式。

2、扇形交换机（Fanout Exchange）：发所有接收到的消息全部发送的交换机所绑定的队列，不需要思考，速度最快。是一种广播模式。

3、主题交换机（Topic Exchange）：routing key根据一定的规则进行匹配，*：表示一个单词；#表示任意数量单词。当一个队列的绑定键为#的时候，这个队列将会无视消息的路由键，接收所有的消息。

4、首部交换机（Header Exchange）：忽略了routing key ,通过headers匹配。将一个交换机声明成首部交换机，绑定一个队列的时候，定义一个 Hash 的数据结构，消息发送的时候，会携带一组 hash 数据结构的信息，当 Hash 的内容匹配上的时候，消息就会被写入队列。

绑定交换机和队列的时候，Hash 结构中要求携带一个键 “x-match”，这个键的 Value 可以是 any 或者 all，这代表消息携带的 Hash 是需要全部匹配 (all)，还是仅匹配一个键 (any) 就可以了。相比直连交换机，首部交换机的优势是匹配的规则不被限定为字符串 (string)。

匹配规则 x-match 有下列两种类型：

x-match = all ：表示所有的键值对都匹配才能接受到消息

x-match = any ：表示只要有键值对匹配就能接受到消息

死信：

当消息过期，超时无人消费；要投递的消息满了，无法投递；消费者使用basic.reject或basic.nack声明消费失败，并且消息的request参数设置为false。

2、消息丢失了怎么办

1.生产者弄丢了数据，可以开启rabbitMq的事务同步机制，在发送数据之前开启事务channel.txSelect()，然后再发送消息，如果消息没有被rabbitMq成功接收到，那么生产者就会收到异常消息，此时就能通过channel.txRollback()回滚事务，然后重新发送消息。发送成功后通过channel.txCommit()提交事务。不过事务同步机制比较耗性能，吞吐量会下降。

为了避免数据丢失，还可以采用confirm机制。事务机制是同步的，提交了事务后，线程会一直阻塞在那。confirm机制是异步的，发送完消息后还能立即发送下一条消息，rabbitMq接收到消息后，会异步回调告诉你消息已经收到了。不过这两种模式是不能共存的。

1、普通confirm模式，客户端发送一条消息后，调用waitForConfirms()方法，等待服务端确认，如果返回false，或者一段时间内没有反应，客户端就会重新发送一次消息。

2、批量confirm模式，发送一批消息后，调用waitForConfirms()方法，然后服务端统一处理。

3、异步confirm模式，客户端发送了一条或多条消息后，服务端确认了之后会执行一个回调方法。

2、消费者消息丢失，可以开启rabbitMq持久化，将消息写入磁盘中。如果mq挂了，再次启动时，会重新读取磁盘中的消息。

设置持久化：

1、创建queue队列时，可以将队列设置成持久化；

2、发送消息时，将消息的deliveryMode=2，设置消息持久化，这样就能将把消息写入磁盘中。

如果消息还未来得及写入磁盘中就挂了，也会造成消息丢失。所以必须将持久化和confirm机制配合在一起，这样即使消息还未来得及写入进磁盘中，只要消息还未给生产者ack确认，客户端也能重新发送消息。

3、消费者消息丢失，必须关闭自动ack机制，使用手动ack机制。

3、消息的幂等性、

单独mq不能保证消息重复消费，只能从业务的角度来判断消息是否重复消费。

3、rabbitMq的高可用

1、rabbitMq有三种模式，单机模式，普通集群模式，镜像集群模式。

普通集群，消费者随机从一个实例中获取数据，如果这个队列的实例宕机了，只能等实例恢复后，才能重新消费。

镜像集群，在mq控制管理后台添加镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。每个rabbitMq节点都有队列的完整镜像，每次写消息的时候，都会将消息同步到多个实例的queue上。

4、日志追踪

firehose,tracing

5、使用场景

1、不是实时的，并且需要性能；

2、mq是异步的，性能高

rabbitMq遵循了amqp协议