码迷,mamicode.com
首页 > 其他好文 > 详细

常用消息中间件对比

时间:2020-04-12 14:15:04      阅读:78      评论:0      收藏:0      [点我收藏+]

标签:开源   adb   注册   概念   队列   lang   实现   消费者   损坏   

一、Kafka、RabbitMQ、Redis消息中间件对比

在分布式系统中、消息中间件常用于系统间的数据交换,
按照实际业务需求场景以及运维成本,可以选择适合自己的产品.

二、相关概念介绍

  • 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决定的。极限情况下丢消息,例如:主写入消息后,主机器宕机,并硬盘损坏

常用消息中间件对比

标签:开源   adb   注册   概念   队列   lang   实现   消费者   损坏   

原文地址:https://www.cnblogs.com/wangchengshi/p/12684925.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!