选择取决于你的微服务到底需要什么。两者相比都有一些不同。

RabbitMQ简介

参与者：
1.消费者
1.发布者
1.兑换
1.路线
流程从发布者开始，发布者向交换发送消息，交换是一个中间件层，它知道如何将消息路由到队列，使用者可以定义他们从哪个队列使用（通过定义绑定），RabbitMQ将消息推送到使用者，一旦使用和确认到达，消息就从队列中删除。生产者、消费者以及RabbitMQ本身都可以集群化，并且具有高可用性。
"Kafka"
参与者是谁
1.消费者/消费者群体
1.制作人
1.Kafka源接

1. KafkaFlume连接
   1.主题和主题划分
   1.Kafka流
   1.经纪人
   1.Zookeeper
   Kafka是一个健壮的系统，在游戏中有几个成员。但是一旦你很好地理解了流程，这就变得容易管理和使用。生产者将消息记录发送到主题，主题是记录发布到的类别或提要名称，它可以被分区，为了获得更好的性能，消费者订阅了一个主题并开始从它拉取消息，当一个主题被分区时，然后每个分区得到它自己的消费者示例，我们把同一消费者的所有示例称为消费者组。在Kafka中，消息总是保留在主题中，即使它们被消费（限制时间由保留策略定义）此外，Kafka使用顺序磁盘I/O，这种方法提高了Kafka的性能，使其成为队列实现中的领先选择，也是大数据用例的安全选择。

"如果你需要，就用Kafka“
1.时间旅行/持久/提交日志
1.许多消费者对同一条消息
1.高吞吐量
1.流处理
1.可复制性
1.高可用性
1.消息顺序

如有需要，请使用RabbitMq：

1.灵活路由
1.优先级队列
1.标准协议消息队列
For more info

为了选择消息代理，我认为此列表非常有用。

Supported programming languages：您可能应该选择一个支持多种编程语言的服务器。
Supported messaging standards：消息代理是否支持任何标准（如AMQP和STOMP），或者它是否是专有的？
Messaging order：消息代理是否保留消息的顺序？
Delivery guarantees：经纪人提供什么样的交货保证？
Persistence：消息是否持久保存到磁盘，并且能够在代理崩溃后继续存在？
Durability：如果使用者重新连接到消息代理，它是否会收到断开连接时发送的消息？
Scalability：消息代理的可伸缩性如何？
Latency：什么是端到端延迟？
Competing consumers：消息代理是否支持相互竞争的使用者？

| Kafka|兔子MQ|
| - -|- -|
| 这是一个分布式流媒体平台，采用发布订阅模式。|它是一个消息代理，在发布-订阅和基于队列的模型上工作。|
| 没有现成的重试和DLQ支持|支持重试和现成的DLQ（通过DLX）。|
| 使用者无法专门过滤消息。|主题交换和标头交换有助于基于使用者的邮件过滤。|
| 消息将保留到其有效期。|邮件在阅读后立即消失。|
| 不支持计划或延迟的邮件路由。|支持消息的计划和延迟路由。|
| 水平缩放|垂直缩放|
| 基于拉动的方法|基于拉动的方法|
| 支持使用者组的事件重放|无法重播事件|