常见的就大概就是这几种，其他比较冷门的就不说了。

咱们面试的时候大概率会被问你为什么使用某个MQ，而不用其他MQ呢。这时候如果你不知道，回答一个：老大让用了，咱们就用呗。
那这次面试不说凉凉，也肯定是要减分的，因为你在工作中没有自己思考，这样的话就只是搬砖工而已。

下面就用一个表格说一说这几个MQ的优缺点

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
单机吞吐量	万级，吞吐量比RocketMQ和kafka要低了一个数量级	万级，吞吐量比RocketMQ和kafka要低了一个数量级	10万级，RocketMQ也是一种可以支撑高吞吐量的一种MQ	10万级，这是kafka最大的优点就是高吞吐量。 一般配合大数据类的系统进行实时数据计算或者日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百、几千个的级别，但是吞吐量会有较小幅度的下降 。这是RocketMQ的一个大优势，在同等机器数量下，可以支撑大量的topic	topic从几十个到几百个的时候吞吐量会有大幅度的下降，所以在同等机器数量下kafka尽量保证topic数量不要太多，如果要支撑大量的topic，建议增加跟多的主机资源
时效性	ms级	微秒级，这是RabbitMQ的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，同一个数据在不同主机备份，即使少数服务宕机也能保证数据不丢失，不会不可用
核心特点	MQ领域的功能及其完备	基于erlang开发，所以并发能力很强，性能极好延时极低	MQ功能较为完善，还是分布式的，拓展性好	功能较为简单，支持主要的MQ功能，在大数据领域的实时数据计算和日志采集等领域被大规模使用，是事实上的标准
优劣势总结	非常成熟，在业内的大量公司和项目中都有运用。 偶尔会有丢失消息的概率，而且，现在社区的国内应用越来越少。官方现在对ActiveMQ 5.X的维护越来越少，而且确实是基于解耦和异步使用的，较少在大规模吞吐量的使用场景	erlang语言开发的，性能极好；而且开源提供的管理界面用起来也很好用，国内近几年互联网公司用RabbitMQ也多了起来。但是问题也在于此，RabbitMQ吞吐量确实会低一些，而且语言是erlang，有能力去做源码优化的公司能有几个。那就只能依赖开源社区的维护和更新修复bug。而且 RabbitMQ集群动态扩展会很麻烦，不过这个应该还好，主要是erlang语言我们很难自己做维护和支持	接口简单易用，毕竟是阿里在使用，品牌有保障。 日处理消息可以达到百亿级别之多，可以做到大规模的吞吐，性能也是非常好。分布式扩展方便，社区维护也还行，可靠性和可用性是ok的，还可以支持大规模的topic数量，支持复杂的MQ业务场景。 而且一个很大的优势在于阿里出品的都是java系的，我们可以自己阅读源码，比较容易掌控。 社区活跃度相对一般，文档相对简单一些。还有就是这个必定很依赖阿里维护，万一这个技术被他们抛弃，那要做好自己维护的准备。	kafka的特点很明显就是仅仅提供很少的核心功能，但是提供超高的吞吐量和ms级的延迟，极高的可用性、可靠性，而且可用分布式任意扩展。 同时kafka支撑较少的topic即可，来保持较高的吞吐量。 但是kafka唯一的一点劣势就是消息有重复消费的风险，这样一来就可能对数据的准确性造成一些轻微的影响。其实在大数据系统中这一点轻微影响还是可以忽略。 kafka的特性天然适合大数据的实时计算以及日志采集。

那么详细的优劣点说完了，简单总结一下的话就是

ActiveMQ	RabbitMQ	RocketMQ	kafka
可能存在消息丢失，吞吐量万级，社区不够活跃，可能会遇到不可解决的bug	性能好，延迟低，erlang语言开发难维护。 集群动态扩展比较麻烦	支持大规模topic高吞吐量，分布式架构并且具备高可用性，阿里的开源项目，社区相对活跃，即使官网不维护了，本公司也要有实力自己维护。	分布式扩展性极好，高可用性，不怕宕机。需要解决重复消费的风险。适合大数据系统方面