支持client和user级别，通过主动设置可将流控作用于生产者或消费者。
支持，但力度较Kafka弱。
支持
顺序性的条件比较苛刻，需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能，从某种意义上来说不算支持顺序性。
优先级队列
性能
高吞吐量的分布式发布订阅消息系统。RabbitMQ在于routing，而Kafka在于streaming
RabbitMQ
与Kafka相似
客户端级别的支持
消息回溯
事务性消息
重试队列
对于确保消息在生产者和消费者之间进行传输而言一般有三种传输保障（delivery guarantee）：At most once，至多一次，消息可能丢失，但绝不会重复传输；At least once，至少一次，消息绝不会丢，但是可能会重复；Exactly once，精确一次，每条消息肯定会被传输一次且仅一次。
消息堆积
起源于金融系统，用于在分布式系统中存储转发消息。
基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面。
幂等性
在开启幂等、事务功能的时候会使其性能降低Kafka的吞吐量要比RabbitMQ高出1至2个数量级
拉模式
不支持
支持。Kafka对于广播消费的支持相对而言更加正统。
安全机制
由于某些原因消息无法被正确的投递，为了确保消息不会被无故的丢弃，一般将其置于一个特殊角色的队列，这个队列一般称之为font color=\"#e57373\
只支持定义协议，目前几个主流版本间存在兼容性问题。
支持。RabbitMQ中可以采用Firehose或者rabbitmq_tracing插件实现。不过开启rabbitmq_tracing插件件会大幅影响性能，不建议生产环境开启，反倒是可以使用Firehose与外部链路系统结合提供高细腻度的消息追踪支持。
支持。一般情况下，内存堆积达到特定阈值时会影响其性能，但这不是绝对的。如果考虑到吞吐这因素，Kafka的堆积效率比RabbitMQ总体上要高很多。
VS
RabbitMQ本身就是AMQP协议的实现，同时支持MQTT、STOMP等协议。
支持。建议优先级大小设置在0-10之间。
RabbitMQ是典型的内存式堆积；Kafka是一种典型的磁盘式堆积。磁盘的容量会比内存的容量要大得多，对于磁盘式的堆积其堆积能力就是整个磁盘的大小。从另外一个角度讲，消息堆积也为消息中间件提供了冗余存储的功能。
不支持。但是二次封装一下也非常简单。
消息一般有两种传递模式：点对点（P2P，Point-to-Point）模式和发布/订阅（Pub/Sub）模式。对于点对点的模式而言，消息被消费以后，队列中不会再存储，所以消息消费者不可能消费到已经被消费的消息。发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题（topic），主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题中订阅消息。RabbitMQ是一种典型的点对点模式，而Kafka是一种典型的发布订阅模式。但是RabbitMQ中可以通过设置交换器类型来实现发布订阅模式而达到广播消费的效果，Kafka中也能以点对点的形式消费
不支持。RabbitMQ中可以参考延迟队列实现一个重试队列，二次封装比较简单。如果要在Kafka中实现重试队列，首先得实现延迟队列的功能，相对比较复杂。
延迟队列
支持单个生产者单分区单会话的幂等性。
多租户
消费模式
消息追踪
Kafka
推模式+拉模式
消息过滤
（TLS/SSL、SASL）身份认证和（读写）权限控制
流量控制
不支持。RabbitMQ中消息一旦被确认消费就会被标记删除。
支持。Kafka支持按照offset和timestamp两种维度进行消息回溯。
11111
广播消费
在开启rabbitmq_tracing插件的时候也会极大的影响其性能RabbitMQ的单机QPS在万级别之内，而Kafka的单机QPS可以维持在十万级别，甚至可以达到百万级。
多协议支持
持久化
支持单分区（partition）级别的顺序性。
死信队列
不支持。消息追踪可以通过外部系统来支持，但是支持粒度没有内置的细腻。
消息顺序性
