RocketMQ基础认知系列1一典型消息中间件对比分析

中间件对比

ZeroMQ 

一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。ZeroMQ是网络通信中新的一层，介于应用层和传输层之间（按照TCP/IP划分），其是一个可伸缩层，可并行运行，分散在分布式系统间。

特点：扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码。

官网：http://zeromq.org/ 参考：https://blog.csdn.net/w174504744/article/details/73187697

RabbitMQ

一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。

特点：具备erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护

官网：http://www.rabbitmq.com/ 参考：https://blog.csdn.net/whoamiyang/article/details/54954780

ActiveMQ

Apache所提供的一个开源的消息系统，完全采用Java来实现，因此，它能很好地支持J2EE提出的JMS（Java Message Service,即Java消息服务）规范。JMS是一组Java应用程序接口，它提供消息的创建、发送、读取等一系列服务。JMS提供了一组公共应用程序接口和响应的语法，类似于Java数据库的统一访问接口JDBC,它是一种与厂商无关的API，使得Java程序能够与不同厂商的消息组件很好地进行通信。

特点：悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列.

官网：http://activemq.apache.org/  参考：https://www.cnblogs.com/jaycekon/p/6225058.html

Redis

个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。

特点：更多的用于缓存，作为消息队列使用的场景较少。

官网：https://redis.io/

kafka

最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

特点：基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的是用于日志收集和传输，0.8开始支持复制，不支持事务，适合产生大量数据的互联网服务的数据收集业务。

优点：
可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
高性能。Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
容错性。Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。
缺点：
重复消息。Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
消息乱序。Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
复杂性。Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。

官网：http://kafka.apache.org/ 参考：https://blog.csdn.net/ychenfeng/article/details/74980531

RocketMQ

阿里巴巴的MQ中间件，在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费，可以在broker端进行消息过滤.

针对消息中间件的选择可以从以下方面进行考虑：(主要对比ActiveMQ和RocketMQ)
     优先级：我们的项目对此需求不是特别明显，RocketMQ需要新建一个特殊队列来接收优先级高的队列，无法实现从0-65535这种细粒度的控制，ActiveMQ可以精细控制
     顺序：我们的消息总线中的消息应该都是无状态的，所以对消息的处理顺序没有严格的要求，如果有特殊要求的话可以在业务层进行控制，activeMQ无法保证严格的顺序，RocketMQ可以保证严格的消费顺序
    持久化：都支持
   稳定性：RoketMQ在稳定性上可能更值得信赖，支持多种集群方案，毕竟已经撑过几个双十一
   消息过滤：ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息，RocketMQ可在broker端进行过滤，对于我们的消息总线，这里可以节省大量的网络传输是否会有消息重发造成的重复消费：RocketMQ可以保证，ActiveMQ无法保证
   回溯消费：即重新将某一个时刻之前的消息重新消费一遍，我们对于这种需求应该很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的队列是持久化到硬盘的，定期进行清除
          事务：都支持
  定时消费：RocketMQ支持
   消息堆积：就是当缓存消息的内存满了之后的解决方案，一种是丢弃策略，这种不不会影响吞吐量，还有一种就是将消息持久化到磁盘，这种会影响吞吐量，在评估影响程度上，RocketMQ的成绩稍微好一点

  客户端不在线：RocketMQ可以在客户端上线后继续将未消费的消息推送到客户端

图示说明[引用]