RabbitMQ和Kafka

 

起因

最近公司RabbitMQ的集群出了点问题,然后有些亲就说RabbitMQ慢且不好用,是一个瓶颈,不如换成Kafka。而我本人,使用RabbitMQ有一点久了,认为这个事情应当辩证的去看。所以就在没事的时候简单的看了看RabbitMQ的代码。但是我并没有看太多Kafka的代码,我只简单提下。

关于Kafka

根据Kafka官方的文档,Kafka可以被认为一个高大上的集群消息中间件,但是读了下以前一个朋友给的部署文档和Kafka的官方的文档。发现Kafka确实不错,真的可以说是集群消息中间件。

  1. 用topic来进行消息管理,每个topic包含多个part,每个part对应一个逻辑log,有多个segment组成。

  2. segment中的消息id由其逻辑位置决定,可以用消息id直接定位到消息的存储位置,避免id到位置的额外映射。

  3. 生产者发到某个topic的消息会被均匀的分布到多个part上,broker收到消息会写入最后的segment文件中,当某个segment上的消息条数达到配置值或消息发布时间超过阈值时,segment上的消息会被flush到磁盘,只有flush到磁盘上的消息消费者才能收到。并且通过rolling的机制,保证segment的文件不至于过大。

  4. 消费者可以rewind back到任意位置重新进行消费,当消费者故障时,可以选择最小的offset进行重新读取消费消息。

是不是看起来很爽,但是深入往下看,发现了一些深坑

  1. Kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。但是part只会被consumer group内的一个consumer消费,故kafka保证每个parti内的消息会被顺序的消费。

  2. broker没有副本机制,一旦broker宕机,该broker的消息将都不可用。同时broker是无状态的,broker不保存消费者的状态,由消费者自己保存。无状态导也致消息的删除成为难题,所以Kafka选择消息保存一定时间后会被删除。

  3. 大量的依赖Zookeeper,需要Zookeeper来管理broker与consumer的动态加入与离开。以及消费关系及每个partion的消费信息。

看到这里,你如果还明白我说这些深坑是什么意思,那就请带入运维场景和特定故障场景思考下。我稍后会说一下这些坑会带来什么问题。

关于RabbitMQ

RabbitMQ是使用Erlang开发的一个消息队列,可以构建成集群,也可以单独使用。

根据测试,RabbitMQ在不使用ACK机制的,Msg大小为1K的情况下,QPS可达6W+。再双方ACK机制,Msg大小为1K的情况下,QPS瞬间降到了1W+。从某种意义上RabbitMQ还真是慢,但是我们需要思考下。

  1. 我们真的每个消息都能到1K吗?

  2. 我们真的需要双方都对消息ACK的系统吗?

好了,如果两个回答都是YES,那么RabbitMQ就是慢的。如果是No,那么RabbitMQ还是一个非常快的队列。

RabbitMQ慢有几个原因:

  1. RabbitMQ做为一个Broker,不单单做到了简单的数据转发功能,还保证了单个队列上的数据有序,即便是有多个消费者和多个生产者。

  2. RabbitMQ的策略是实时转发,而不像Kafka那样等待刷盘之后才让消费者来消费。

  3. 如果消费者和生产者不对等,会产生大量的磁盘IO操作,进行消息换出。

RabbitMQ为什么不好用:

  1. AMQP协议本身比较复杂,参数比较多。

  2. Erlang写的,很多人不熟悉,并且Mnesia出现问题好多人解决不了。

RabbitMQ和Kafka相比没价值了吗?

很多亲们读到这里,就会想RabbitMQ好像也不怎么样呀。和Kafka相比没什么价值可言了,但是我前面说了一些Kafka的坑,我就在这里面揭示一下。

  1. Kafka大量依赖Zookeeper,它的broker并不保存任何状态,如果Zookeeper集群不幸悲剧了,那么整个Kafka集群的消息就全完蛋了。

  2. 上面问题有人会说这概率好小,我也同样认为这个概率很小,那么一个broker当机呢?当一个broker当机了整个消息队列由于负载均衡的算法,在一瞬间消费者和生产者之间的消息就全乱掉了。很多需要保证消息顺序的系统一下子就完蛋了。

这就是RabbitMQ存在的价值和意义,同时RabbitMQ使用了MirrorQueue的机制,也可以做到多个机器进行热备。

RabbitMQ该怎么用

  1. RabbitMQ的消息应当尽可能的小,并且只用来处理实时且要高可靠性的消息。

  2. 消费者和生产者的能力尽量对等,否则消息堆积会严重影响RabbitMQ的性能。

  3. 集群部署,使用热备,保证消息的可靠性。

Kafka该怎么用

  1. 应当有一个非常好的运维监控系统,不单单要监控Kafka本身,还要监控Zookeeper。

  2. 对消息顺序不依赖,且不是那么实时的系统。

  3. 对消息丢失并不那么敏感的系统。


本文转载自:http://www.cnblogs.com/ziyouchutuwenwu/p/4786818.html