面试官问你对消息队列都有哪些了解？我的回答让面试官点赞

为什么使用消息队列啊？消息队列有什么优点和缺点啊？kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景？

（如需要牛客网的java面经电子版本，可以加个关注，私信我，免费分享）
1.消息队列的常见使用场景吧，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰
解耦：A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。

解耦的思想：

异步： A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。

异步思想：

削峰： 每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。

削峰思想：

2.消息队列有什么优点和缺点啊？
优点 ：解耦、异步、削峰
缺点 ：
1.系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
2.系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
3.一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

3.kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景？



优劣势总结
ActiveMQ
优点：非常成熟，功能强大，在业内大量的公司以及项目中都有应用
缺点： 偶尔会有较低概率丢失消息

RabbitMQ
优点：性能极其好，延时很低；吞吐量到万级，MQ功能比较完备
缺点：RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。

RocketMQ
优点：接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，
缺点：社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些

Kafka
优点：提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
缺点：有可能消息重复消费

如何保证消息队列的高可用啊？

1.RabbitMQ的高可用性
RabbitMQ是比较有代表性的，因为是基于主从做高可用性的
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
1.单机模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
2.普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。

3.镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue

2.kafka的高可用性