本文旨在说明我遇到的每一个MQ的特性和适用场景，拒绝适用简单的性能来比较，借用康德的话：
- 这些不同的MQ有些根本不是一个东西，单纯的性能比较没有意义，而比较每个MQ的特性才有更意义。
- 如果你尝试用性能来作选择，那么Kafka胜出，其他你很弱鸡的MQ没入你的法眼，但是那其实这些"失败者"可能才是真正适合于你业务的东西。
作为一个初学者，看到非常多的MQ产品我眼花缭乱，于是乎我整理了我理解的每个MQ的性质和其适用场景，给各位道友参考，少走点弯路。
出生
- RabbitMQ：遵循AMQP协议，由内在高并发的erlang语言开发，用在实时的对可靠性要求比较高的消息传递上。
- 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进行支持。