系统架构对比
Kafka
RocketMQ
数据存储
- Kafka一个topic后面分为多个partition，每个partition对应一个日志文件跟一个索引文件
- RocketMQ一个topic可分为多个ConsumeQueue，每个ConsumeQueue存储的是每个消息在commitlog这个文件的地址，但是消息存在于commitlog中
数据可靠性
- RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication
- Kafka使用异步刷盘方式，异步Replication
RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。另外Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是这里有个问题，由于是异步Replication，那么切换后会有数据丢失，同时Leader如果重启后，会与已经存在的Leader产生数据冲突。开源版本的RocketMQ不支持Master宕机，Slave自动切换为Master，阿里云版本的RocketMQ支持自动切换特性。
性能对比
- Kafka单机写入TPS约在百万条/秒，消息大小10个字节
- RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节
为什么Kafka吞吐量高于RocketMQ
Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker
RocketMQ为什么没有这么做？
- Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题
- Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错
- Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。
- 缓存的功能完全可以由上层业务完成。
Kafka消息保存在多个segment文件，RocketMQ消息都是保存在一个commitLog文件，相比起来写入性能更高。
- Kafka使用短轮询方式，实时性取决于轮询间隔时间
- RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。
- Kafka不支持定时消息
- RocketMQ支持两类定时消息
- 开源版本RocketMQ仅支持定时Level
- 阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间
- Kafka不支持分布式事务消息，Kafka从0.11版本开始支持事务消息，
- RocketMQ支持分布式事务消息
- Kafka不支持消息查询
- RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）
Broker端消息过滤
- Kafka不支持Broker端的消息过滤
- RocketMQ支持两种Broker端消息过滤方式
- 根据Message Tag来过滤，相当于子topic概念
- 向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
