RabbitMQ和Kafka对比

前言

开源社区有好多优秀的队列中间件，好比RabbitMQ和Kafka，每一个队列都貌似有其特性，在进行工程选择时，每每眼花缭乱，不知所措。对于RabbitMQ和Kafka，到底应该选哪一个？

RabbitMQ架构

概念

RabbitMQ是一个分布式系统broker：每一个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列操做请求。master queue：每一个队列都分为一个主队列和若干个镜像队列。mirror queue：镜像队列，做为master queue的备份。在master queue所在节点挂掉以后，系统把mirror queue提高为master queue，负责处理客户端队列操做请求。注意，mirror queue只作镜像，设计目的不是为了承担客户端读写压力。

如上图所示，集群中有两个节点，每一个节点上有一个broker，每一个broker负责本机上队列的维护，而且borker之间能够互相通讯。集群中有两个队列A和B，每一个队列都分为master queue和mirror queue（备份）。那么队列上的生产消费怎么实现的呢？

队列消费

如上图有两个consumer消费队列A，这两个consumer连在了集群的不一样机器上。RabbitMQ集群中的任何一个节点都拥有集群上全部队列的元信息，因此链接到集群中的任何一个节点均可以，主要区别在于有的consumer连在master queue所在节点，有的连在非master queue节点上。

由于mirror queue要和master queue保持一致，故须要同步机制，正由于一致性的限制，致使全部的读写操做都必须都操做在master queue上（想一想，为啥读也要从master queue中读？和数据库读写分离是不同的。），而后由master节点同步操做到mirror queue所在的节点。即便consumer链接到了非master queue节点，该consumer的操做也会被路由到master queue所在的节点上，这样才能进行消费。

队列生产

原理和消费同样，若是链接到非 master queue 节点，则路由过去。

不足因为master queue单节点，致使性能瓶颈，吞吐量受限。虽然为了提升性能，内部使用了Erlang这个语言实现，可是终究摆脱不了架构设计上的致命缺陷。

Kafka

说实话，Kafka我以为就是看到了RabbitMQ这个缺陷才设计出的一个改进版，改进的点就是：把一个队列的单一master变成多个master，即一台机器扛不住qps，那么我就用多台机器扛qps，把一个队列的流量均匀分散在多台机器上不就能够了么？注意，多个master之间的数据没有交集，即一条消息要么发送到这个master queue，要么发送到另一个master queue。

这里面的每一个master queue 在Kafka中叫作Partition，即一个分片。一个队列有多个主分片，每一个主分片又有若干副分片作备份，同步机制相似于RabbitMQ。

如上图，咱们省略了不一样的queue，假设集群上只有一个queue（Kafka中叫Topic）。每一个生产者随机把消息发送到主分片上，以后主分片再同步给副分片。

队列读取的时候虚拟出一个Group的概念，一个Topic内部的消息，只会路由到同Group内的一个consumer上，同一个Group中的consumer消费的消息是不同的；Group之间共享一个Topic，看起来就是一个队列的多个拷贝。因此，为了达到多个Group共享一个Topic数据，Kafka并不会像RabbitMQ那样消息消费完毕立马删除，而是必须在后台配置保存日期，即只保存最近一段时间的消息，超过这个时间的消息就会从磁盘删除，这样就保证了在一个时间段内，Topic数据对全部Group可见（这个特性使得Kafka很是适合作一个公司的数据总线）。队列读一样是读主分片，而且为了优化性能，消费者与主分片有一一的对应关系，若是消费者数目大于分片数，则存在某些消费者得不到消息。

因而可知，Kafka绝对是为了高吞吐量设计的，好比设置分片数为100，那么就有100台机器去扛一个Topic的流量，固然比RabbitMQ的单机性能好。

总结

本文只作了Kafka和RabbitMQ的对比，可是开源队列岂止这两个，ZeroMQ，RocketMQ，JMQ等等，时间有限也就没有细看，故不在本文比较范围以内。

因此，别再被这些五花八门的队列迷惑了，从架构上找出关键差异，并结合本身的实际需求（好比本文就只单单从吞吐量一个需求来考察）轻轻松松搞定选型。最后总结以下：

吞吐量较低：Kafka和RabbitMQ均可以。吞吐量高：Kafka。本文内容参考自RabbitMQ和KafKa官方文档，因此真要搞懂一个中间件的原理最好去看官方文档，文档里面有详细的设计方案，咱们能够本身进行设计方案的对比，从而找出符合本身实际状况的中间件。转自：https://www.cnblogs.com/haolujun/p/9632835.html