Kafka RabbitMQ

起因

最近公司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. 对消息丢失并不那么敏感的系统。