消息中间件的对比

ActiveMQ、RabbitMQ、RocketMQ、KafkaPulsar

ActiveMQ:

  单机吞吐量:万级

  可用性:高,基于主从架构实现高可用性

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

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

  总结:

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

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

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

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

RabbitMQ
  单机吞吐量:万级

  可用性:高,基于主从架构实现高可用性

  


  消息可靠性:

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

  总结:  

    erlang语言开发,性能极其好,延时很低;

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

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

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

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

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

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


RocketMQ
  单机吞吐量:十万级

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

  时效性:ms级

  可用性:非常高,分布式架构

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

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

  总结:

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

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

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

Kafka
  单机吞吐量:十万级,最大的优点,就是吞吐量高。

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

  时效性:ms级

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

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

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

  总结:

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

    同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量

    kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略

Pulasr与Rocket MQ的对比

原文链接:https://www.cnblogs.com/mengchunchen/p/9999774.html

  

 

  

原文地址:https://www.cnblogs.com/cgy-home/p/12040459.html