选型比较 - Kafka VS RabbitMQ

常见消息队列比对

比较方向	RabbitMQ	Kafka	RocketMQ
资料文档	多(有一些不错的书, 网上资料多)	中(有kafka作者自己写的书, 网上资料也有一些)	少(没有专门写rocketmq的书, 网上的资料良莠不齐, 官方文档很简洁, 但是对技术细节没有过多的描述)
开发语言	Erlang	Scala	Java
支持的协议	AMQP	自定义的一套协议	自定义的一套协议
消息存储	内存,磁盘(支持少量的消息堆积)	磁盘(支持大量的消息堆积)	磁盘(支持大量的消息堆积)
事务消息	支持	支持	支持
管理界面	好	一般	无
消息重复	支持at least once, at most once	支持at least once, at most once	支持at least once
吞吐量	单机万级	单机十万级(入页缓存, 刷入磁盘前重启会丢数据)	单机万级
顺序消息	在满足一些前提的情况下, 支持消息的顺序性	支持	支持 文本居右
消息确认	支持	支持	支持

What is RabbitMQ

General purpose message broker, based around message queues, designed with a smart broker / passive consumer model

Why RabbitMQ

多种语言提供的支持, 以及丰富的插件库

更加丰富/ 完善的监控功能

强大的路由

• Easy to scale by adding/removing competing consumers on a single queue
• Can be configured for consistency, high availability, low latency, high throughput
• Cluster rolling upgrades via feature glags
• Easy to get started
• Supports strict ordering
• Wider use cases e.g., event driven microservices, RPC, ETL(with SCDF), enterprise message bus, pub-sub messaging, real-time analytics(with Reactor and RabbitMQ Reactive API)
• 通过在单个队列上添加/删除竞争消费者，可以轻松扩展
• 可以配置为一致性、高可用性、低延迟、高吞吐量
• 通过功能玻璃进行集群滚动升级
• 轻松入门
• 支持严格排序
• 更广泛的用例，例如，事件驱动的微服务、RPC、ETL（使用SCDF）、企业消息总线、发布订阅消息、实时分析（使用Reactor和RabbitMQ反应式API）

What is Kafka

Distributed & partitioned commit log with messaging semantics
Distributed real-time streaming platform

Why Kafka

• Very high throughput with data guarantees
• Massive scale
• Ability to replay events
• De-facto standard for streaming platform
• Ability to plug-n-play consumer groups on a topic
• Supports strict ordering
• Replace complex data architectures
• Broad ecosystem
• Wider use cases - pub-sub messaging, events driven microservices, logs store, streaming, event sourcing, CDC, enterprise data pipelines
• 非常高的吞吐量和数据保证
• 大规模
• 回放事件的能力
• 流媒体平台的事实标准
• 能够就某个主题对消费者群体进行即插即用的能力
• 支持严格排序
• 取代复杂的数据体系结构
• 广阔的生态系统
• 更广泛的使用案例-发布订阅消息、事件驱动的微服务、日志存储、流媒体、事件源、CDC、企业数据管道

When to use RabbitMQ over Kafka

• If you don’t have specific Kafka requirements, then RabbitMQ gives you greater flexibility, can meet high throughput and real-time event-processing needs and has lower cost of operations
• Evolving application requirements
• Decoupled producer and consumers ( using exchanges )
• Consumers independently bring their own queue that binds to exchanges
• Consuming applications don’t need to process messages that aren’t relevant
• 如果您没有特定的Kafka需求，那么RabbitMQ将为您提供更大的灵活性，可以满足高吞吐量和实时事件处理需求，并且具有更低的操作成本
• 不断变化的应用程序需求
• 生产者和消费者分离（使用交换）
• 消费者独立地将自己的队列绑定到交换机
• 使用应用程序不需要处理不相关的消息

When to use Kafka Over RabbitMQ

• Streaming platform
• Extremely high throughput
• Joining multiple streams or streams and tables to enrich the data
• Scale ( typically beyond 5 brokers )
• Replay
• 流媒体平台
• 极高的吞吐量
• 连接多个流或流和表以丰富数据
• 规模（通常超过5家经纪人）
• 重放

Challenges in RabbitMQ

• Operational complexity in resolving network partitions
• Queues are single-threaded
• Scaling brokers > 3 becomes complicated and can have negative performance impacts
• No events replay
• Does not natively support stateful streaming use cases ( but can do so with Reactor + RabbitMQ Reactive API with external store such as Redis )
• 解析网络分区的操作复杂性
• 队列是单线程的
• 扩展brokers>3会变得复杂，并可能对性能产生负面影响
• 无事件重播
• 本机不支持有状态的流式处理用例（但可以通过Reactor+RabbitMQ Reactive API和外部存储（如Redis）实现）

Challenges in Kafka

• No free lunch - operational complexity
• Requires a separate Zookeeper cluster
• Requires meticulous planning to select partition count
• Storage management overheads
• Careful coordination needed between teams writing consumer groups and producers
• No out of box management & monitoring console
• Streaming API support restricted mainly to Java
• No out of box solution for upgrade
• 没有免费午餐-操作复杂性
• 需要单独的Zookeeper群集
• 需要精心规划以选择分区计数
• 存储管理开销
• 编写消费者群体和生产者的团队之间需要仔细协调
• 无现成的管理和监控控制台
• 流式API支持主要局限于Java
• 没有现成的升级解决方案