1.那你说一下你们在项目里是怎么用消息队列的？
业务流程.

2.那你说说用消息队列都有什么优点和缺点？
解耦:  举例说明
异步:  举例说明
削峰平谷: 举例说明

3.kafka、activemq、rabbitmq、rocketmq都有什么区别及适合哪些场景？
单机吞吐量:
    1.activeMq      万级，吞吐量比RocketMQ和Kafka要低了一个数量级
    2.rabbitMq      万级，吞吐量比RocketMQ和Kafka要低了一个数量级
    3.rocketMq      10万级，RocketMQ也是可以支撑高吞吐的一种MQ
    4.kafka         10万级别，这是kafka最大的优点，就是吞吐量高。

topic数量对吞吐量的影响:
    1.activeMq      
    2.rabbitMq      
    3.rocketMq      topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降(优势,支持大量的topic)
    4.kafka         topic从几十个到几百个的时候，吞吐量会大幅度下降(kafka要避免大量的topic)

时效性:
    1.activeMq      ms级
    2.rabbitMq      微秒级 , 因为rabbitMq使用的erlang语言,专门针对高并发的语言,延迟最低.
    3.rocketMq      ms级
    4.kafka         ms级以内

可用性:
    1.activeMq      高，基于主从架构实现高可用性
    2.rabbitMq      高，基于主从架构实现高可用性
    3.rocketMq      非常高，分布式架构
    4.kafka         非常高，分布式架构

消息可靠性:
    1.activeMq      有较低的概率丢失数据
    2.rabbitMq      优化后,可以做到0丢失
    3.rocketMq      优化后,可以做到0丢失
    4.kafka          优化后,可以做到0丢失

功能支持:
    1.activeMq      符合jms标准,功能齐全.
    2.rabbitMq      基于erlang语言开发.
    3.rocketMq      MQ功能比较完善,支持分布式
    4.kafka         功能较为简单,支持分布式

优劣势总结:
    1.activeMq      非常成熟，功能强大，在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息,而且现在社区以及国内应用都越来越少，
        官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用.

    2.rabbitMq      erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用
        社区相对比较活跃，几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，
        这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，
        你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。
        其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。

    3.rocketMq      接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，
        社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，阿里出品都是java系的，
        我们可以自己阅读源码，定制自己公司的MQ，可以掌控社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走
        的有些系统要迁移需要修改大量代码还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的.

    4.kafka         kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
        同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，
        在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集



MQ入门级问题:
面试官心理分析

其实面试官主要是想看看：

（1）第一，你知道不知道你们系统里为什么要用消息队列这个东西？

（2）第二，你既然用了消息队列这个东西，你知道不知道用了有什么好处？

（3）第三，既然你用了MQ，可能是某一种MQ，那么你当时做没做过调研啊？


4.那你们是如何保证消息队列的高可用啊？
如果有人问到你MQ的知识，高可用是必问的，因为系统中添加了MQ,会有很多缺点，mq宕机了,你的系统也就出问题了，
有好多，导致系统可用性降低，等等。所以只要你用了MQ，接下来问的一些要点肯定就是围绕着MQ的那些缺点怎么来解决了。
（1）RabbitMQ的高可用性
    RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
    rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
        1）单机模式
            就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
        2）普通集群模式
            意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。
            完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，
            就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，
            后者导致单实例性能瓶颈。而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，
            让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。所以这个事儿就比较尴尬了，
            这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
        3）镜像集群模式
            这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次
            你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。
            坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，
            你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue那么怎么开启这个镜像集群模式呢？我这里简单说一下，
            避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据
            同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

（2）kafka的高可用性
    kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，
    每个partition就放一部分数据。这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。实际上rabbitmq之类的，
    并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，
    也是每个节点都放这个queue的完整数据。
    kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
    kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，
    那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。
    只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。
    kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，
    那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。
    这就有所谓的高可用性了。写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步
    好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
    消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。




5.如何保证消息不被重复消费啊？如何保证消费的时候是幂等的啊？
其实这个很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？
这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性.
Mq只能保证消息数据不会丢失,但是不能保证数据不会重复发送,我们怎么保证他的幂等性.
结合我们的业务逻辑来思考.
（1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下.   
（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性
（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，
    先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
（4）还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来
    得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据


6.如何保证消息的可靠性传输啊？要是消息丢失了怎么办啊？
    通过rabbitmq的配置,保证数据的可靠性传输.
    1.生产者出丢失数据.
    有两种机制:
        1.rabbitmq的事务控制, 但是事务控制是同步的会阻塞进程, 所以效率比较低, 吞吐量会下来
        2.confirm机制,是一个异步操作, rabbitmq接收到消息后,会回调生产者的方法,告诉生产者,接收到消息,而且效率高,推荐使用.

    2.rabbitmq丢失数据
        rabbitmq接收到消息后,需要把消息保存到本地,需要开启rabbitmq的持久化,接收到消息后,把消息保存到本地,就算rabbotmq挂了,也会去本地读取未处理的消息.
        持久化需要两步,第一:创建queue的时候需要将其设置为持久化. 第二: 发送消息的时候将消息的deliveryMode设置为2,就是把消息设置为持久化.

    3.消费者丢失数据
        使用rabbitmq提供的ack机制,改为手动模式,自动模式的情况下,消费者接收到消息就会告诉rabbitmq,我已经接收到消息了,如果此时消费者挂了,数据是没有处理的,而且
        rabbitmq认为你已经处理了. 手动模式,在我们处理完此条数据后,再去通知rabbitmq,保证数据一定被处理了.


7.那如何保证消息的顺序性？
    举个例子: 一个mysql同步另一个mysql,通过mq来同步, 此时来了三条消息  
        消息1: 插入一条数据
        消息2: 修改一条数据
        消息3: 删除一条数据
        如果my中没有顺序性,先执行了消息3,在去执行消息2,再去执行消息1. 那么数据库之间的消息肯定不同步.
    其实真正的解决办法很简单,这种需要顺序行的消息,单独创建出来一个队列和一个消费者去接收,有先后顺序的数据,指定发送这个队列即可.        

1.那你说一下你们在项目里是怎么用消息队列的？
业务流程.

2.那你说说用消息队列都有什么优点和缺点？
解耦:  举例说明
异步:  举例说明
削峰平谷: 举例说明

3.kafka、activemq、rabbitmq、rocketmq都有什么区别及适合哪些场景？
单机吞吐量:
    1.activeMq      万级，吞吐量比RocketMQ和Kafka要低了一个数量级
    2.rabbitMq      万级，吞吐量比RocketMQ和Kafka要低了一个数量级
    3.rocketMq      10万级，RocketMQ也是可以支撑高吞吐的一种MQ
    4.kafka         10万级别，这是kafka最大的优点，就是吞吐量高。

topic数量对吞吐量的影响:
    1.activeMq      
    2.rabbitMq      
    3.rocketMq      topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降(优势,支持大量的topic)
    4.kafka         topic从几十个到几百个的时候，吞吐量会大幅度下降(kafka要避免大量的topic)

时效性:
    1.activeMq      ms级
    2.rabbitMq      微秒级 , 因为rabbitMq使用的erlang语言,专门针对高并发的语言,延迟最低.
    3.rocketMq      ms级
    4.kafka         ms级以内

可用性:
    1.activeMq      高，基于主从架构实现高可用性
    2.rabbitMq      高，基于主从架构实现高可用性
    3.rocketMq      非常高，分布式架构
    4.kafka         非常高，分布式架构

消息可靠性:
    1.activeMq      有较低的概率丢失数据
    2.rabbitMq      优化后,可以做到0丢失
    3.rocketMq      优化后,可以做到0丢失
    4.kafka          优化后,可以做到0丢失

功能支持:
    1.activeMq      符合jms标准,功能齐全.
    2.rabbitMq      基于erlang语言开发.
    3.rocketMq      MQ功能比较完善,支持分布式
    4.kafka         功能较为简单,支持分布式

优劣势总结:
    1.activeMq      非常成熟，功能强大，在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息,而且现在社区以及国内应用都越来越少，
        官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用.

    2.rabbitMq      erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用
        社区相对比较活跃，几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，
        这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，
        你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。
        其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。

    3.rocketMq      接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，
        社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，阿里出品都是java系的，
        我们可以自己阅读源码，定制自己公司的MQ，可以掌控社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走
        的有些系统要迁移需要修改大量代码还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的.

    4.kafka         kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
        同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，
        在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集



MQ入门级问题:
面试官心理分析

其实面试官主要是想看看：

（1）第一，你知道不知道你们系统里为什么要用消息队列这个东西？

（2）第二，你既然用了消息队列这个东西，你知道不知道用了有什么好处？

（3）第三，既然你用了MQ，可能是某一种MQ，那么你当时做没做过调研啊？


4.那你们是如何保证消息队列的高可用啊？
如果有人问到你MQ的知识，高可用是必问的，因为系统中添加了MQ,会有很多缺点，mq宕机了,你的系统也就出问题了，
有好多，导致系统可用性降低，等等。所以只要你用了MQ，接下来问的一些要点肯定就是围绕着MQ的那些缺点怎么来解决了。
（1）RabbitMQ的高可用性
    RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
    rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
        1）单机模式
            就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
        2）普通集群模式
            意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。
            完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，
            就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，
            后者导致单实例性能瓶颈。而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，
            让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。所以这个事儿就比较尴尬了，
            这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
        3）镜像集群模式
            这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次
            你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。
            坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，
            你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue那么怎么开启这个镜像集群模式呢？我这里简单说一下，
            避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据
            同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

（2）kafka的高可用性
    kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，
    每个partition就放一部分数据。这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。实际上rabbitmq之类的，
    并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，
    也是每个节点都放这个queue的完整数据。
    kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
    kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，
    那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。
    只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。
    kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，
    那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。
    这就有所谓的高可用性了。写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步
    好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
    消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。




5.如何保证消息不被重复消费啊？如何保证消费的时候是幂等的啊？
其实这个很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？
这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性.
Mq只能保证消息数据不会丢失,但是不能保证数据不会重复发送,我们怎么保证他的幂等性.
结合我们的业务逻辑来思考.
（1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下.   
（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性
（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，
    先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
（4）还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来
    得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据


6.如何保证消息的可靠性传输啊？要是消息丢失了怎么办啊？
    通过rabbitmq的配置,保证数据的可靠性传输.
    1.生产者出丢失数据.
    有两种机制:
        1.rabbitmq的事务控制, 但是事务控制是同步的会阻塞进程, 所以效率比较低, 吞吐量会下来
        2.confirm机制,是一个异步操作, rabbitmq接收到消息后,会回调生产者的方法,告诉生产者,接收到消息,而且效率高,推荐使用.

    2.rabbitmq丢失数据
        rabbitmq接收到消息后,需要把消息保存到本地,需要开启rabbitmq的持久化,接收到消息后,把消息保存到本地,就算rabbotmq挂了,也会去本地读取未处理的消息.
        持久化需要两步,第一:创建queue的时候需要将其设置为持久化. 第二: 发送消息的时候将消息的deliveryMode设置为2,就是把消息设置为持久化.

    3.消费者丢失数据
        使用rabbitmq提供的ack机制,改为手动模式,自动模式的情况下,消费者接收到消息就会告诉rabbitmq,我已经接收到消息了,如果此时消费者挂了,数据是没有处理的,而且
        rabbitmq认为你已经处理了. 手动模式,在我们处理完此条数据后,再去通知rabbitmq,保证数据一定被处理了.


7.那如何保证消息的顺序性？
    举个例子: 一个mysql同步另一个mysql,通过mq来同步, 此时来了三条消息  
        消息1: 插入一条数据
        消息2: 修改一条数据
        消息3: 删除一条数据
        如果my中没有顺序性,先执行了消息3,在去执行消息2,再去执行消息1. 那么数据库之间的消息肯定不同步.
    其实真正的解决办法很简单,这种需要顺序行的消息,单独创建出来一个队列和一个消费者去接收,有先后顺序的数据,指定发送这个队列即可.