对Kafka、ActiveMQ、RabbitMQ、RocketMQ的区别对比

好久没有写博客了，目前几种主流的消息中间件：

一、为什么要使用消息队列?

分析:一个用消息队列的人，不知道为啥用，这就有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。
回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰

(1)解耦

传统模式:

                                

传统模式的缺点：

系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

中间件模式:         

中间件模式的的优点：

将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

(2)异步

传统模式:

                           
传统模式的缺点：

一些非必要的业务逻辑以同步的方式运行，太耗费时间。

中间件模式:

                                              
中间件模式的的优点：

将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度

(3)削峰

传统模式

传统模式的缺点：

并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

中间件模式:

中间件模式的的优点：

系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

二.几种消息中间件的区别

(1)ActiveMQ

　　单机吞吐量：万级

　　topic数量都吞吐量的影响：

　　时效性：ms级

　　可用性：高，基于主从架构实现高可用性

　　消息可靠性：有较低的概率丢失数据

　　功能支持：MQ领域的功能极其完备

　　总结：

　　　　非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用  

　　　　偶尔会有较低概率丢失消息  

　　　　现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本   

　　　　主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用

(2)RabbitMQ

　　单机吞吐量：万级

　　topic数量都吞吐量的影响：

　　时效性：微秒级，延时低是一大特点。

　　可用性：高，基于主从架构实现高可用性

　　消息可靠性：

　　功能支持：基于erlang开发，所以并发能力很强，性能极其好，延时很低

　　总结：　　

　　　　erlang语言开发，性能极其好，延时很低；  

　　　　吞吐量到万级，MQ功能比较完备  

　　　　开源提供的管理界面非常棒，用起来很好用  

　　　　社区相对比较活跃，几乎每个月都发布几个版本分  

　　　　在国内一些互联网公司近几年用rabbitmq也比较多一些   但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。  

　　　　erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。  

　　　　rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。

 (3)RocketMQ

　　单机吞吐量：十万级

　　topic数量都吞吐量的影响：topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。可支持大量topic是一大优势。

　　时效性：ms级

　　可用性：非常高，分布式架构

　　消息可靠性：经过参数优化配置，消息可以做到0丢失

　　功能支持：MQ功能较为完善，还是分布式的，扩展性好

　　总结：

　　　　接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景  

　　　　而且一个很大的优势在于，源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控  

　　　　社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码  

(4)Kafka

　　单机吞吐量：十万级，最大的优点，就是吞吐量高。

　　topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源

　　时效性：ms级

　　可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用

　　消息可靠性：经过参数优化配置，消息可以做到0丢失

　　功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

(5)小结：

　　kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展， 

同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量。kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。

三、如何选择合适的消息中间件

(1).从社区活跃度

按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。

(2).持久化消息比较

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。

(3).综合技术实现

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。

(4).高并发

毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。

通过比较，RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上，  RabbitMq  胜于  Kafka  （理论上）。

另外，Kafka 的定位主要在日志等方面，因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。

还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

四、一些建议

如果我们系统中已经有选择Kafka，或RabbitMq，并且完全可以满足现在的业务，建议就不用重复去增加和造轮子。

可以在Kafka和RabbitMq  中选择一个适合自己团队和业务的，这个才是最重要的。但是毋庸置疑现阶段，综合考虑没有第三选择。

如果你对消息中间件是小白，建议先学习RabbitMq , Kafka。