kafka和rabbitMq的对比

发布/订阅模式不同

• 点对点和发布/订阅

点对点：
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。这里要注意：
消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

发布/订阅
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费

• kafka点对点和发布订阅的模式：

Kafka只支持消息持久化，消费端为拉模型，消费状态和订阅关系由客户端端负责维护，消息消费完后不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了

• RabbitMQ点对点和发布订阅的模式：

点对点：只能被一个消费者消费

当RabbitMQ需要支持多订阅时，发布者发送的消息通过路由同时写到多个Queue，不同订阅组消费此消息。
RabbitMQ既支持内存队列也支持持久化队列，消费端为推模型，消费状态和订阅关系由服务端负责维护，消息消费完后立即删除，不保留历史消息，（但因为有多份queue所以可以被多人消费）。所以支持多订阅时，消息会多个拷贝

消息应答机制

RabbitMQ具有生产者confirm机制以及消费者的消息应答机制ack

Kafka不具有应答机制

消息的顺序

rabbitMQ中，在一个队列里面，rabbitMQ的消息是严格顺序的，按照先进先出的则

kafka中，在同一个partition中消息是有序的，但是生产者put到kafka中数据会分布在不同的partition中，所以总体是无序的

吞吐量

根据测试，RabbitMQ在不使用ACK机制的，Msg大小为1K的情况下，QPS可达6W＋。再双方ACK机制，Msg大小为1K的情况下，QPS瞬间降到了1W＋。
Kafka具有巨大的吞吐量，数据的存储以及获取是本地磁盘的批量处理，可以达到百万/s。

可靠性

RabbitMQ使用了MirrorQueue的机制，也可以做到多个机器进行热备。

Kafka的broker支持主备模式。

持久化

RabbitMQ支持持久化。

Kafka 是一个持久性消息存储。

使用场景

rabbitMQ

• RabbitMQ的消息应当尽可能的小，并且只用来处理实时且要高可靠性的消息。
•  消费者和生产者的能力尽量对等，否则消息堆积会严重影响RabbitMQ的性能。
•  集群部署，使用热备，保证消息的可靠性。

kafka

• 应当有一个非常好的运维监控系统，不单单要监控Kafka本身，还要监控Zookeeper。(kafka强烈的依赖于zookeeper,如果zookeeper挂掉了，那么Kafka也不行了)
•  对消息顺序不依赖，且不是那么实时的系统。
•  对消息丢失并不那么敏感的系统。
•  从 A 到 B 的流传输，无需复杂的路由，最大吞吐量可达每秒 100k 以上。