高并发架构队列：Kafka、RocketMQ、RabbitMQ的优劣势全方位汇总

高并发架构队列：Kafka、RocketMQ、RabbitMQ的优劣势全方位汇总

消息队里在开发中的地位是核心基础，如果想提高系统的处理瓶颈上线，MQ队列是首选的组件。目前主流的队列有三种：Kafka，RocketMQ,RabbitMQ。可能有人会有疑问，怎么没有ActiveMQ。因为经过多年的发展，目前ActiveMQ的社区非常不活跃，其开始逐渐势微，这里暂不介绍。

在业务中如何对MQ进行选型？首先是立足于本职场景，不要为了使用而使用。而从技术维度来分析，个人认为主要包括：可用性，主从切换，数据可靠性，消息写入性，处理消息性能稳定性，消息堆积处理能力，集群环境下彼此的复制能力，消息投递能力等。对于其他方面的诸如：部署依赖，管理后台，文档，持久化方式等，是我们选型的考虑因素之一，但相比较重要性而言，还是决定性的因素，而决定性的因为是上面第一点中提到的诸多因素。

如下内容即为Kafka、RocketMQ、RabbitMQ 三者在诸多维度的比较汇总内容。

综上所述：

MQ选型首先要基于本身的业务场景，对于目前整个行业已知的印象：

现在确实越来越多的公司，会去用RocketMQ，确实很不错，因为其是java开发的，大公司基础架构研发实力较强，可以进行本地化的功能完善，比如滴滴，其就是在RocketMQ基础上进行改造，当然，如果可以hold住现有现场，就无需改造了。

中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择，这里说的中小型公司是相对于技术研发能力来讲进行推荐的，因为RabbitMQ是erlang语言开发的，这就阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高，所以，对于一般性规模rabbitMQ是都没有问题的，只是进行改造难度太大，是从这个角度推荐中小型公司使用。

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

以上为全部内容。