• kafka与rabbitMQ选型比较
  • 1.实际场景选择
  • 2.应用场景方面
  • 3.架构模型方面
  • 4.吞吐量比较
  • 5.集群负载均衡方面
  • 6.综合比较

kafka与rabbitMQ选型比较

1.实际场景选择

RabbitMQ：交易数据,金融场景。具有较高的严谨性，数据丢失的可能性更小，同时具备更高的实时性；
kafka：高吞吐量，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；

2.应用场景方面

RabbitMQ：用于实时的，对可靠性要求较高的消息传递上。
kafka：用于处于活跃的流式数据，大数据量的数据处理上。

3.架构模型方面

RabbitMQ：以broker为中心，有消息的确认机制
kafka：以consumer为中心，无消息的确认机制

4.吞吐量比较

RabbitMQ：支持消息的可靠的传递，支持事务，不支持批量操作，基于存储的可靠性的要求存储可以采用内存或硬盘，吞吐量小。
kafka：内部采用消息的批量处理，数据的存储和获取是本地磁盘顺序批量操作，消息处理的效率高，吞吐量高。

5.集群负载均衡方面

RabbitMQ：本身不支持负载均衡，需要loadbalancer的支持

kafka：采用zookeeper对集群中的broker，consumer进行管理，可以注册topic到zookeeper上，通过zookeeper的协调机制，producer保存对应的topic的broker信息，可以随机或者轮询发送到broker上，producer可以基于语义指定分片，消息发送到broker的某个分片上。

6.综合比较

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

kafka:
1.应当有一个非常好的运维监控系统，不单单要监控Kafka本身，还要监控Zookeeper。(kafka强烈的依赖于zookeeper,如果zookeeper挂掉了，那么Kafka也不行了)
2.对消息顺序不依赖，且不是那么实时的系统。
3.对消息丢失并不那么敏感的系统。

标签：rabbitMQ,zookeeper,broker,RabbitMQ,kafka,选型,消息,吞吐量
来源： https://www.cnblogs.com/guyouyin123/p/16115450.html