我们找工作的话，一般中高级开发就会被问到mq相关方面的一些问题

  1.什么是消息队列

 2.为什么要用消息队列

3.缺点有什么？

4.消息队列分别有哪些？

5.它们有什么区别？

一,什么是消息队列

 消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它

  可以这样看 队列 从字面上来看   像不像是排好队的一队干饭人，食堂大妈给他们打饭，肯定时先到先打吧，排后面的先打到饭，肯定会引起混乱（先进先出） 

二,为什么要使用消息队列

   消息队列的核心就是 解耦、异步、削峰

1.解耦

 当服务之间 有互相调用的情况下    A服务要发一个消息到其它多个服务，每多一个服务要重新修改这个服务的相关代码，耦合性非常高，也妨碍服务横向扩张

当把这个消息发给消息队列时，需要消息的系统自己从消息队列中订阅，就不需要额外修改代码来处理这件事，也就做到了很好的解耦性

2.异步

当模块有引用其他模块时，a模块  调用了b 再调用了c 再调用了d  如果是同步进行的话  会非常耗时如果有一个中间件，a调用了中间件  就算调用成功了  b,c,d 订阅该消息  这样既加快了响应时间，又不会影响到相应的业务

3.削峰

很多网站访问都有高低峰   打车什么的，上下班肯定是高峰期，都知道我们数据库的连接读写资源是有限的，如果在高峰期的时候，大量数据一下涌进，可能会造成数据库连接的异常

如果请求先写入到中间件  再由服务根据自己数据库能处理的并发量去拉取这些消息，就可以很好的解决这些问题，但是难以避免会出现一些消息的积压

三.缺点

1.原来系统之间直接调用，现在加入mq这个中介，如果中介跑路了（挂掉了），那肯定也就就联系不上了，导致整个业务流程全部断线

2.A系统处理完了发送到消息对流后直接返回成功了，用户以为你这个请求就成功了；但是问题是，其他系统消费该消息后，如果当中有一个系统出现了问题，导致数据丢失。最后就会发生数据不一致等问题。

系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

四，消息队列分别有哪些？

ActiveMQ、RocketMQ、RabbitMQ、ZeroMQ、Kafka 等等等等，一般面试的时候能回答的出来这些就已经是可以的了，当然也有用redis来做这种消息中间件的（偷偷告诉你redis还可以用来做注册中心，redis要抗下所有，哈哈哈）

五，区别是什么？

	ActiveMQ	RabbitMQ	RocketMq	Kafka	ZeroMQ
特点	功能齐全，被大量开源项目使用	由于Erlang 语言的并发能力，性能很好	各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好	Kafka的Producer、Broker和Consumer之间采用的是一套自行设计的基于TCP层的协议。Kafka的这套协议完全是为了Kafka自身的业务需求而定制的，而非要实现一套类似于Protocol Buffer的通用协议	低延时，高性能，最高 43万条消息每秒
开发语言	Java	Erlang	Java	scala	C
支持的协议	OpenWire、 STOMP、 REST、XMPP、 AMQP,MQTT	AMQP,STOMP，MQTT	自己定义的一 套(社区提供 JMS--不成熟)	PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL。	TCP、UDP
持久化	内存、文件、数据库	内存、文件	磁盘文件	内存，文件，数据库	在消息发送端保存
事务	支持	不支持	支持	支持	不支持
集群	支持	支持	支持	支持	不支持
负载均衡	支持	支持	支持	支持	不支持
管理界面	一般	好	无社区有 web console   实现	好	无
部署方式	独立、嵌入	独立	独立	独立	独立
吞吐量	万级	万级	10万级	10万级	10万级
时效性	ms级	us级	ms级	ms级以内
评价	优点：    成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端； 缺点： 根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了，目前社区不活跃，且对 5.x 维护较少； Activemq 不适合用于上千个队列的应用场景	优点：   由于erlang语言的特性，mq 性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客户端可用   缺点：   erlang语言难度较 大。集群不支持动态扩展。	优点：    模型简单，接口易用（JMS   的接口很多场合并不太实用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产 品均使用rocketmq。集群规模大概在50 台左右，单日处理消息上百亿；性能非常好，可以大量堆 积消息在broker   中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本更新很快。  缺点：   没有在 mq 核心中去实现JMS 等接口，	高吞吐量：Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB） 　　持久化数据存储：可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication 防止数据丢失。 　　分布式系统易于扩展：所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。 　　客户端状态维护：消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。	调用的socket接口较多。 TCP是一对一的连接。 编程需要关注很多socket细节问题。 不支持跨平台编程。 需要自行处理分包、组包问题。 流式传输时需处理粘包、半包问题。 需自行处理网络异常，比如连接异常中断、重连等。 服务端和客户端启动有先后。 自行处理IO模型。 自行实现消息的缓存。 自行实现对消息的加密。