转自通九大神的博客
起因
最近公司RabbitMQ的集群出了点问题，然后有些亲就说RabbitMQ慢且不好用，是一个瓶颈，不如换成Kafka。而我本人，使用RabbitMQ有一点久了，认为这个事情应当辩证的去看。所以就在没事的时候简单的看了看RabbitMQ的代码。但是我并没有看太多Kafka的代码，我只简单提下。
关于Kafka
根据Kafka官方的文档，Kafka可以被认为一个高大上的集群消息中间件，但是读了下以前一个朋友给的部署文档和Kafka的官方的文档。发现Kafka确实不错，真的可以说是集群消息中间件。
用topic来进行消息管理，每个topic包含多个part，每个part对应一个逻辑log，有多个segment组成。
segment中的消息id由其逻辑位置决定，可以用消息id直接定位到消息的存储位置，避免id到位置的额外映射。
生产者发到某个topic的消息会被均匀的分布到多个part上，broker收到消息会写入最后的segment文件中，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息消费者才能收到。并且通过rolling的机制，保证segment的文件不至于过大。
消费者可以rewind back到任意位置重新进行消费，当消费者故障时，可以选择最小的offset进行重新读取消费消息。
是不是看起来很爽，但是深入往下看，发现了一些深坑
Kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。但是part只会被consumer group内的一个consumer消费，故kafka保证每个parti内的消息会被顺序的消费。
broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。同时broker是无状态的，broker不保存消费者的状态，由消费者自己保存。无状态导也致消息的删除成为难题，所以Kafka选择消息保存一定时间后会被删除。
大量的依赖Zookeeper，需要Zookeeper来管理broker与consumer的动态加入与离开。以及消费关系及每个partion的消费信息。
看到这里，你如果还明白我说这些深坑是什么意思，那就请带入运维场景和特定故障场景思考下。我稍后会说一下这些坑会带来什么问题。
关于RabbitMQ
RabbitMQ是使用Erlang开发的一个消息队列，可以构建成集群，也可以单独使用。
根据测试，RabbitMQ在不使用ACK机制的，Msg大小为1K的情况下，QPS可达6W＋。再双方ACK机制，Msg大小为1K的情况下，QPS瞬间降到了1W＋。从某种意义上RabbitMQ还真是慢，但是我们需要思考下。
我们真的每个消息都能到1K吗？
我们真的需要双方都对消息ACK的系统吗？
好了，如果两个回答都是YES，那么RabbitMQ就是慢的。如果是No，那么RabbitMQ还是一个非常快的队列。
RabbitMQ慢有几个原因：
RabbitMQ做为一个Broker，不单单做到了简单的数据转发功能，还保证了单个队列上的数据有序，即便是有多个消费者和多个生产者。
RabbitMQ的策略是实时转发，而不像Kafka那样等待刷盘之后才让消费者来消费。
如果消费者和生产者不对等，会产生大量的磁盘IO操作，进行消息换出。
RabbitMQ为什么不好用：
AMQP协议本身比较复杂，参数比较多。
Erlang写的，很多人不熟悉，并且Mnesia出现问题好多人解决不了。
RabbitMQ和Kafka相比没价值了吗？
很多亲们读到这里，就会想RabbitMQ好像也不怎么样呀。和Kafka相比没什么价值可言了，但是我前面说了一些Kafka的坑，我就在这里面揭示一下。
Kafka大量依赖Zookeeper，它的broker并不保存任何状态，如果Zookeeper集群不幸悲剧了，那么整个Kafka集群的消息就全完蛋了。
上面问题有人会说这概率好小，我也同样认为这个概率很小，那么一个broker当机呢？当一个broker当机了整个消息队列由于负载均衡的算法，在一瞬间消费者和生产者之间的消息就全乱掉了。很多需要保证消息顺序的系统一下子就完蛋了。
这就是RabbitMQ存在的价值和意义，同时RabbitMQ使用了MirrorQueue的机制，也可以做到多个机器进行热备。
RabbitMQ该怎么用
RabbitMQ的消息应当尽可能的小，并且只用来处理实时且要高可靠性的消息。
消费者和生产者的能力尽量对等，否则消息堆积会严重影响RabbitMQ的性能。
集群部署，使用热备，保证消息的可靠性。
Kafka该怎么用
应当有一个非常好的运维监控系统，不单单要监控Kafka本身，还要监控Zookeeper。
对消息顺序不依赖，且不是那么实时的系统。
对消息丢失并不那么敏感的系统。