消息队列

1. 为什么要使用消息队列？

1. 解耦
2. 削峰

一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ作解耦。

2. 消息队列有什么优缺点？

1. 系统可用性降低，如果mq挂了很多系统都无法正常运行
2. 系统复杂性提高，如何保证消息不被重复消费？如何处理消息丢失？如何保证消息传递的顺序性？
3. 一致性问题，一个功能的实现需要ABC模块执行完成才算成功，结果AB执行成功了，C却失败了

3. kafka，activemq，rabbitmq，rocketmq有什么区别以及适用那些场景？

消息中间件	单机吞吐量和时效性	可用性和功能支持	优点	缺点
activeMQ	万级别和ms级别	高，功能及其完善	非常成熟	较低概率丢失数据，社区活跃越来越少
rabbitMQ	万级别和μs级别	高，基于erlang开发，并发能力很强，性能好，延迟很低	社区活跃，开源提供的管理界面非常棒	吞吐量低一些，erlang开源看不懂
rocketMQ	十万级别和ms级别	分布式架构可用性非常高，扩展性好	阿里出品，Java开源，通过配置可以做到数据0丢失	做好该技术被抛弃的准备
kafka	十万级别和ms级别	分布式架构可用性非常高，功能较简单	提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展	消息重复消费，那么对数据准确性会造成极其轻微的影响

4. 应用场景

1. 一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了。后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高；

2. 不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄

3. 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择

4. 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范

5. RabbitMQ高可用

5.1 普通级群模式

1. 在多台机器上启动多个rabbitmq实例，每个机器启动一个。创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。当你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
2. 缺点：可能会在rabbitmq集群内部产生大量的数据传输。可用性几乎没有保障，如果queue所在的节点宕机了，就会导致数据丢失。

5.2 镜像集群模式（高可用，非分布式）

1. 创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
2. 好处：任何一个节点宕机了，其他节点还包含queue完整的数据
3. 缺点：如果queue数据量很大，导致机器无法容纳。
4. 开启方式：在rabbitmq后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

6. RabbitMQ的重读消费问题

7. RabbitMQ数据丢失

1. 生产者向rabbitmq写数据，在网络传输中出现为你或rabbitmq没有保存成功导致数据丢失了。
2. rabbitmq接收到数据后，还没来着急保存到内存中就挂掉了。
3. 消费者拿到数据还没来得及处理自己就挂了，rabbitmq以为消费者处理完了。

7.1 解决生产者丢失数据的问题

7.1.1 同步，可能造成阻塞

1. 选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息。
2. 如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。

7.1.2 异步，一般用法

1. channel开启confirm模式，每次写消息都会分配到一个id，通过回调给生产者通知是否接收到这个消息来达到消息接受的确定。
2. 如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

7.2 解决RabbitMQ丢失数据的问题

1. 持久化磁盘
2. 在创建queue的时候设置为持久化
3. 发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化。
4. rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。

7.3 解决消费者丢失数据的问题

1. 关闭AutoAck
2. 通过API来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。
3. 如果还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。