介绍一下rabbitmq
RabbitMQ是Erlang语言开发的基于AMQP的一款消息中间件，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先发送给交换机，然后由交换机转发给对应的队列。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。
它里边有5种数据传递方式
第一种是简单模型，一个生产者，一个队列，一个消费者，队列只能被一个消费者监听，所以生产者将消息发给队列之后，只能有一个消费者收到消息
第二种是工作模型，一个生产者，一个队列，多个消费者，队列可以被多个消费者监听，但是生产者将消息发给队列之后，还是只能有一个消费者接收到消息
后边三种都叫订阅模型，这三种里边引入了交换机的概念，具体的区分是根据交换机的类型区分的，在这三种模式种，生产者把消息发送给交换机，交换机不负责存储消息，由交换机发送给指定的队列，消费者监听队列消费消息。
首先是fanout类型，这种叫广播模式，生产者将消息发送给交换机，交换机会将消息转发给所有绑定到到当前交换机的队列中，对应监听队列的消费者都能收到消息，但是，如果没有队列绑定到这个交换机，消息会被mq丢弃。
接着是direct类型，这种叫定向模式，也叫路由模式，这种模式中，队列在绑定交换机的时候，同时指定了自己的routing key，可以理解为一个路由标示，生产者在发送消息给交换机的时候，同时指定要发送给的routing key，这时候，交换机就会根据这个routing key来定向的发送给对应的队列，对应监听该routing key的队列的消费者就能收到消息，但是如果交换机没有找到对应的routing key，消息会被丢弃。
最后是topic模式，这种叫通配符模式，队列在绑定交换机的时候，同时指定了自己的routing key，生产者在发送消息给交换机的时候，同时指定要发送给的routing key 的通配符，一般这个routing key是由多个单词用.的方式隔开的，通配符中，#号可以匹配一个或者多个单词，*号只能匹配一个单词，例如生产者指定的通配符为a.#，可以匹配到的routing key有：a.b、a.b.c等，如果是a.*的话，只能匹配a.b或者是a.c这样的routing key。每个队列绑定到交换机的时候可以定义多个routing key，交换机会跟据指定的通配符，发送到匹配通配符的routing key 对应的队列中，对应的消费者就可以收到消息了，但是，如果没有符合通配符的routing key ，消息会被丢弃
当然，在生产中使用的时候，为了避免mq宕掉等造成消息丢失的问题，我们都会配置持久化措施，在rabbitmq里，需要将交换机持和队列和消息持久化，这样消息就会被持久化到磁盘中，不会因为突发的断电等情况导致消息丢失
2、如何保证消息确定消息发送成功，并且被消费成功，有什么保障措施
解析：这里不用背，这里的问法会有很多中，这道题中问了两部分
第一部分是确保发送成功，还可以被问成：消息发送失败了怎么办，或者如何保证消息可靠传输
第二部分是确保消费成功，还可以被问成：消息消费时，发生异常了，消息已经被消费了，怎么办等
首先，需要确保消息被发送成功，rabbitmq中提供了事物和confirm的机制，事物的话，就类似于数据库的事物，开启，执行，提交，如果过程中发生任何异常，就会触发回滚机制，我们可以在回滚中加入一些逻辑处理，重新发送或者日志记录，同时配置生产者确认的机制，就是在消息发送之后，该消息会被指定唯一的ID，如果有消息成功被交换机转发到队列之后，mq会给生产者发送ack确认，如果没有队列接收消息，那么会发送错误回执消息给生产者，生产者可以尝试重试发送，或者日志记录。通过这些可以看出，mq会增加一些保障性措施，必然会导致性能有一些下降，如果要保证消息的严格一致性，那么可以配置这些，如果消息不重要，或者允许有丢失的情况，那么可以不用配置，这样的话能提升mq的性能。
其次就是，消息确保发送成功之后，还要确保消息被消费成功，因为在消费者端，如果消息消费时发生异常，又没有做一些处理，那么消息就会丢失，这种情况，可以采取两种方式解决
第一种就是消费端配置手动ACK确认机制，消息被消费完成的时候，手动确认告诉mq消费成功，mq才会删除消息，如果消息被接收了，但是mq没有收到ack确认，那么消息在mq中会变为unacked状态，我们可以通过项目日志或者mq面板监控，当消费者断开连接之后，消息会重新回到队列中，消费者重新连接之后，会再次收到消息。
第二种就是可以结合数据库解决，生产者端发送成功之后，可以在数据库中存储发送的消息和发送时间，并标记状态为未消费状态，消费者端消费完成之后，标记mysql中数据的状态为已经消费。消费者端通过定时任务去数据库跑批检索超时未被消费的消息并重新发送，这种方式可以很好的解决消费失败的问题，但是增加了生产者和消费者之间的耦合度，以及会造成消息重复消费的问题，我们可以在保证消息发送成功的基础上，将上述逻辑放在消费者端，生产者正常发送消息，消费者在收到消息之后，存储到myqsl中，标记状态为未消费，同时ack通知mq确认，然后再消费消息，消息消费成功之后，改变mysql状态为已消费，消费端同时配置定时任务跑批检索数据库，定时重新执行超时未消费的消息。
以上的解决办法都是需要根据实际的业务需求来的，如果消息需要保证强一致性，不能出现任何差错，那么就需要按照前面说的添加对应的配置
我们项目中的mq主要用于数据同步使用的，mysql数据发生变化之后，需要同步到es索引库以及静态化页面中，这里我们配置了生产者确认模式，和消费者手动ack确认机制。
3、如何保证消息不被重复消费
我们可以在生产者端，发送消息时，数据的变动部分，进行md5加密处理，同时配置上一个唯一id，每次发送的数据的唯一id是递增的，相当于版本号的功能，在消费者端，收到消息之后，首先去数据库匹配一下md5值如果数据库中记录的当前记录已经被消费，那么就不进行消费，如果发现数据库没有记录当前消息，或者记录的状态没有被消费，那么才会重新消费该消息
4、RabbitMQ 宕机了怎么处理
RabbitMQ 提供了持久化的机制，将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。持久化队列和非持久化队列的区别是，持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在RabbitMQ 中被管理，而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。而持久化的优点就是消息会一直存在，不会随服务的重启或服务器的宕机而消失。使用的时候需要根据实际需求来判断具体如何使用。
