刘文奇

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

9/29/2018 kafkaredisRabbitmq

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

在分布式系统中，消息中间件常用于系统间的数据交换。

前几天搭建ELKB集群，用了一些队列。Kafka、Redis、RabbitMQ这三个消息中间件对一个简单的对比

按照实际业务需求场景以及运维成本，可以选择是和自己的产品。

# 相关概念性的介绍

  • Kafka

是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。

Kafka主要特点:

  • 基于Pull的模式来处理消息消费。

  • 追求高吞吐量。

  • 一开始的目的就是用于日志收集和传输。

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

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

    ​ AMQP的主要特征

    • 面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
    • AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
    • 主要应用于如： dubbo框架（zookeeper用于注册中心）、spring cloud等

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

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

# 特性对比

# 在应用场景方面

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

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

# 在架构模型方面

  • 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数据；无消息确认机制。

# 在吞吐量方面

  • kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。
  • rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。

# 在可用性方面

  • rabbitMQ支持miror的queue，主queue失效，miror queue接管。

  • kafka的broker支持主备模式。

# 在集群负载均衡方面

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

  • rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

# 应用场景

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

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

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

b) 以下场景你比较适合使用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决定的。极限情况下丢消息，例如：主写入消息后，主机器宕机，并硬盘损坏。