复习RabbitMQ消息队列，顺序消费，保证消息不丢，不重复消费，消息失败，推和拉的使用

1 MQ有什么用？

消息队列有很多使用场景，比较常见的有3个：解耦、异步、削峰。

1、解耦：传统各个模块之间都要时刻关注其他模块的是否更改或者是否挂掉等等，使用消息队列，可以避免模块之间直接调将所需共享的数据放在消息队列中，对于新增业务模块，只要对该类消息感兴趣，即可订阅该类消息
2、异步：不需要立即处理消息，，在之后需要的时候再慢慢处理。
3、削峰：访问量骤增时，消息队列的容量可以配置的很大，如果采用磁盘存储消息，则几乎等于“无限”容量，这样一来，高峰期的消息可以被积压起来，在随后的时间内进行平滑的处理完成，而不至于让系统短时间内无法承载而导致崩溃。

2 说一说生产者与消费者模式

实际上主要是包含了两类线程。一种是生产者线程用于生产数据，另一种是消费者线程用于消费数据，为了解耦生产者和消费者的关系，通常会采用共享的数据区域，就像是一个仓库。生产者生产数据之后直接放置在共享数据区中，并不需要关心消费者的行为。而消费者只需要从共享数据区中去获取数据，就不再需要关心生产者的行为。但是，这个共享数据区域中应该具备这样的线程间并发协作的功能：

如果共享数据区已满的话，阻塞生产者继续生产数据放置入内；
如果共享数据区为空的话，阻塞消费者继续消费数据。
在Java语言中，实现生产者消费者问题时，可以采用三种方式：
使用 Object 的 wait/notify 的消息通知机制；
使用 Lock 的 Condition 的 await/signal 的消息通知机制；
使用 BlockingQueue 实现。

3 消息队列如何保证顺序消费？

不同的消息队列产品，产生消息错乱的原因，以及解决方案是不同的。下面我们以RabbitMQ、Kafka、RocketMQ为例，来说明保证顺序消费的办法。

1、RabbitMQ：
对于 RabbitMQ 来说，导致上面顺序错乱的原因通常是消费者是集群部署，不同的消费者消费到了同一订单的不同的消息。如消费者A执行了增加，消费者B执行了修改，消费者C执行了删除，但是消费者C执行比消费者B快，消费者B又比消费者A快，就会导致消费 binlog 执行到数据库的时候顺序错乱，本该顺序是增加、修改、删除，变成了删除、修改、增加。如下图：

RabbitMQ 的问题是由于不同的消息都发送到了同一个 queue 中，多个消费者都消费同一个 queue 的消息。解决这个问题，我们可以给 RabbitMQ 创建多个 queue，每个消费者固定消费一个 queue 的消息，生产者发送消息的时候，同一个订单号的消息发送到同一个 queue 中，由于同一个 queue 的消息是一定会保证有序的，那么同一个订单号的消息就只会被一个消费者顺序消费，从而保证了消息的顺序性。如下图：

4 消息队列如何保证消息不丢？

丢数据一般分为两种，一种是mq把消息丢了，一种就是消费时将消息丢了。
RabbitMQ丢失消息分为如下几种情况：

1、生产者丢消息：
生产者将数据发送到RabbitMQ的时候，可能在传输过程中因为网络等问题而将数据弄丢了。
2、RabbitMQ自己丢消息：
如果没有开启RabbitMQ的持久化，那么RabbitMQ一旦重启数据就丢了。所以必须开启持久化将消息持久化到磁盘，这样就算RabbitMQ挂了，恢复之后会自动读取之前存储的数据。
3、消费端丢消息：
主要是因为消费者消费时，刚消费到还没有处理，结果消费者就挂了，这样你重启之后，RabbitMQ就认为你已经消费过了，然后就丢了数据。

RabbitMQ可以采用如下方式避免消息丢失：

1、生产者丢消息：

• 使用RabbitMQ提供是事务功能，就是生产者在发送数据之前开启事务，然后发送消息，如果消息没有成功被RabbitMQ接收到，那么生产者会受到异常报错，这时就可以回滚事务，就会变为同步阻塞操作，生产者会阻塞等待是否发送成功，太耗性能会造成吞吐量的下降。
• 可以开启confirm模式。在生产者那里设置开启了confirm模式之后，每次写的消息都会分配一个唯一的id，然后如何写入了RabbitMQ之中，RabbitMQ会给你回传一个ack消息，告诉你这个消息发送OK了。如果RabbitMQ没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试。

2、RabbitMQ自己丢消息：

设置消息持久化到磁盘，设置持久化有两个步骤：

• 创建queue的时候将其设置为持久化的，这样就可以保证RabbitMQ持久化queue的元数据，但是不会持久化queue里面的数据。
• 发送消息的时候讲消息的deliveryMode设置为2，这样消息就会被设为持久化方式，此时RabbitMQ就会将消息持久化到磁盘上。 必须要同时开启这两个才可以。

而且持久化可以跟生产的confirm机制配合起来，只有消息持久化到了磁盘之后，才会通知生产者ack，这样就算是在持久化之前RabbitMQ挂了，数据丢了，生产者收不到ack回调也会进行消息重发。

3、消费端丢消息：
首先关闭RabbitMQ的自动ack，然后每次在确保处理完这个消息之后，在代码里手动调用ack。这样就可以避免消息还没有处理完就ack。

5 消息队列如何保证不重复消费（幂等性）？

想要保证不重复消费，其实还要结合业务来思考，这里给几个思路：

1、在内存中、redis、数据库中建立一个list消费记录，每次消费消息前先扫描一下这个list
2、利用redis的set集合具有不可重复的特性
3、利用数据库唯一主键

6 MQ处理消息失败了怎么办？

一般生产环境中，都会在使用MQ的时候设计两个队列：一个是核心业务队列，一个是死信队列。核心业务队列，就是比如专门用来让订单系统发送订单消息的，然后另外一个死信队列就是用来处理异常情况的。

比如说要是第三方物流系统故障了，此时无法请求，那么仓储系统每次消费到一条订单消息，尝试通知发货和配送，都会遇到对方的接口报错。此时仓储系统就可以把这条消息拒绝访问，或者标志位处理失败！

7 请介绍消息队列推和拉的使用场景

1、推模式：

推模式是服务器端根据用户需要，由目的、按时将用户感兴趣的信息主动发送到用户的客户端。

• 优点：
  1、对用户要求低，方便用户获取需要的信息；
  2、及时性好，服务器端及时地向客户端推送更新动态信息，吞吐量大。
• 缺点：
  1、不能确保发送成功，推模式采用广播方式，只有服务器端和客户端在同一个频道上，推模式才有效，用户才能接收到信息；
  2、没有信息状态跟踪，推模式采用开环控制技术，一个信息推送后的状态，比如客户端是否接收等，无从得知；
  3、针对性较差。推送的信息可能并不能满足客户端的个性化需求。

2、拉模式：

拉模式是客户端主动从服务器端获取信息。

• 优点：
  1、针对性强，能满足客户端的个性化需求；
  2、信息传输量较小，网络中传输的只是客户端的请求和服务器端对该请求的响应；
  服务器端的任务轻。服务器端只是被动接收查询，对客户端的查询请求做出响应。
• 缺点：
  1、实时性较差，针对于服务器端实时更新的信息，客户端难以获取实时信息；
  2、对于客户端用户的要求较高，需要对服务器端具有一定的了解。