常用消息中间件对比

常用消息中间件对比_第1张图片Kafka

 

1.基于Pull的模式来处理消息消费

2.追求高吞吐量

3.一开始的目的就是日志收集和传输

4.0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求、适合产生大量数据的互联网服务的数据收集业务.

 

RabbitMQ

RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现.

AMQP的主要特征

1.面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。

2.AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。

主要应用于如: dubbo框架(zookeeper用于注册中心)、spring cloud等

 

Redis

Redis是一个基于Key-Value对的NoSQL数据库,开发维护很活跃.

虽然他是一个Key-value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用

 

三、特性对比

1.在应用场景方面

RabbitMQ,遵从AMQP协议,由内在高并发的erlang语言开发,用在实时的对可靠性要求比较高的消息传递上.

 

Kafka是Linkedin于2010年12月份开源的消息订阅系统,它主要用于处理活式的流式数据,大数据量的数据处理上.

 

2.在架构模型上

RabbitMQ遵循AMQP协议,RabbitMQ的broker由Exchange,Binding,queue组成,其中exchange和binding组成了消息的路由键;客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费(长连接,queue有消息会推送到consumer端,consumer循环从输入流读取数据)。rabbitMQ以broker为中心;有消息的确认机制。

 

kafka遵从一般的MQ结构,producer,broker,consumer,以consumer为中心,消息的消费信息保存的客户端consumer上,consumer根据消费的点,从broker上批量pull数据;无消息确认机制。

 

3.在吞吐量方面

kafka具有高的吞吐量,内部采用消息的批量处理,zero-copy机制,数据的存储和获取是本地磁盘顺序批量操作,具有O(1)的复杂度,消息处理的效率很高。

rabbitMQ在吞吐量方面稍逊于kafka,他们的出发点不一样,rabbitMQ支持对消息的可靠的传递,支持事务,不支持批量的操作;基于存储的可靠性的要求存储可以采用内存或者硬盘。

 

4.在可用性方面

RabbitMQ支持miror的queue,主queue失效,miror queue接管

kafka的broker支持主备模式

 

5.在集群负载均衡方面

kafka采用zookeeper对集群中的broker、consumer进行管理,可以注册topic到zookeeper上;通过zookeeper的协调机制,producer保存对应topic的broker信息,可以随机或者轮询发送到broker上;并且producer可以基于语义指定分片,消息发送到broker的某分片上。

RabbitMQ的负载均衡需要单独的loadbalancer进行支持.

 

四、应用场景

rabbitmq比kafka可靠,kafka更适合IO高吞吐的处理,比如ELK日志收集

Kafka和RabbitMq一样是通用意图消息代理,他们都是以分布式部署为目的。但是他们对消息语义模型的定义的假设是非常不同的。

 

以下场景你比较适合使用Kafka。你有大量的事件(10万以上/秒)、你需要以分区的,顺序的,至少传递成功一次到混杂了在线和打包消费的消费者、你希望能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意通过论坛/IRC工具得到还在幼儿阶段的软件的支持。

 

以下场景你比较适合使用RabbitMQ。你有较少的事件(2万以上/秒)并且需要通过复杂的路由逻辑去找到消费者、你希望消息传递是可靠的、你并不关心消息传递的顺序、你需要现在就支持集群-节点级别的高可用或则说你需要7*24小时的付费支持(当然也可以通过论坛/IRC工具)

 

redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠

 

redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠。其他的mq和kafka保证可靠但有一些延迟(非实时系统没有保证延迟)。redis-pub/sub断电就清空,而使用redis-list作为消息推送虽然有持久化,也并非完全可靠不会丢。

 

redis是内存数据库!redis他爹做了disque,你要不要试试。mq一般都采用订阅~发布模型,如果你考虑性能,主要关注点就放在消费模型是pull还是push。影响最大的,应该是存储结构。kafka的性能要在topic数量小于64的时候,才能发挥威力。partition决定的。极限情况下丢消息,例如:主写入消息后,主机器宕机,并硬盘损坏

你可能感兴趣的:(java)