为了不便大家更好的选型，小编整顿一份RocketMQ与Kafka的比照文档，心愿能够帮忙到大家。
数据可靠性
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的TPS跑到单机百万，次要是因为Producer端将多个小音讯合并，批量发向Broker。
RocketMQ为什么没有这么做？
Producer通常应用Java语言，缓存过多音讯，GC是个很重大的问题
Producer调用发送音讯接口，音讯未发送到Broker，向业务返回胜利，此时Producer宕机，会导致音讯失落，业务出错
Producer通常为分布式系统，且每台机器都是多线程发送，咱们认为线上的零碎单个Producer每秒产生的数据量无限，不可能上万。
缓存的性能齐全能够由下层业务实现。
单机反对的队列数
Kafka单机超过64个队列/分区，Load会产生显著的飙高景象，队列越多，load越高，发送音讯响应工夫变长
RocketMQ单机反对最高5万个队列，Load不会产生显著变动
队列多有什么益处？
单机能够创立更多Topic，因为每个Topic都是由一批队列组成
Consumer的集群规模和队列数成正比，队列越多，Consumer集群能够越大
音讯投递实时性
Kafka应用短轮询形式，实时性取决于轮询间隔时间
RocketMQ应用长轮询，同Push形式实时性统一，音讯的投递延时通常在几个毫秒。
生产失败重试
Kafka生产失败不反对重试
RocketMQ生产失败反对定时重试，每次重试间隔时间顺延
总结：例如充值类利用，大数据培训以后时刻调用运营商网关，充值失败，可能是对方压力过多，稍后在调用就会胜利，如支付宝到银行扣款也是相似需要。
这里的重试须要牢靠的重试，即失败重试的音讯不因为Consumer宕机导致失落。
严格的音讯程序
Kafka反对音讯程序，然而一台Broker宕机后，就会产生音讯乱序
RocketMQ反对严格的音讯程序，在程序音讯场景下，一台Broker宕机后，发送音讯会失败，然而不会乱序
Mysql Binlog散发须要严格的音讯程序
定时音讯
Kafka不反对定时音讯
RocketMQ反对两类定时音讯
开源版本RocketMQ仅反对定时Level
阿里云ONS反对定时Level，以及指定的毫秒级别的延时工夫
分布式事务音讯
Kafka不反对分布式事务音讯
阿里云ONS反对分布式定时音讯，将来开源版本的RocketMQ也有打算反对分布式事务音讯
音讯查问
Kafka不反对音讯查问
RocketMQ反对依据Message Id查问音讯，也反对依据音讯内容查问音讯（发送音讯时指定一个Message Key，任意字符串，例如指定为订单Id）
总结：音讯查问对于定位音讯失落问题十分有帮忙，例如某个订单解决失败，是音讯没收到还是收到解决出错了。
音讯回溯
Kafka实践上能够依照Offset来回溯音讯
RocketMQ反对依照工夫来回溯音讯，精度毫秒，例如从一天之前的某时某分某秒开始从新生产音讯
总结：典型业务场景如consumer做订单剖析，然而因为程序逻辑或者依赖的零碎产生故障等起因，导致明天生产的音讯全副有效，须要从新从昨天零点开始生产，那么以工夫为终点的音讯重放性能对于业务十分有帮忙。
生产并行度
Kafka的生产并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行生产（每台机器只能开启一个线程），或者一台机器生产（10个线程并行生产）。即生产并行度和分区数统一。
RocketMQ生产并行度分两种状况
程序生产形式并行度同Kafka完全一致
乱序形式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器生产，每台机器100个线程，那么并行度为1000。
音讯轨迹
Kafka不反对音讯轨迹
阿里云ONS反对音讯轨迹
开发语言敌对性
Kafka采纳Scala编写
RocketMQ采纳Java语言编写
Broker端音讯过滤
Kafka不反对Broker端的音讯过滤
RocketMQ反对两种Broker端音讯过滤形式
依据Message Tag来过滤，相当于子topic概念
向服务器上传一段Java代码，能够对音讯做任意模式的过滤，甚至能够做Message Body的过滤拆分。
音讯沉积能力
实践上Kafka要比RocketMQ的沉积能力更强，不过RocketMQ单机也能够反对亿级的音讯沉积能力，咱们认为这个沉积能力曾经齐全能够满足业务需要。
开源社区活跃度
Kafka社区更新较慢
RocketMQ的github社区有250个集体、公司用户注销了联系方式，QQ群超过1000人。
商业反对
Kafka原开发团队成立新公司，目前暂没有相干产品看到
RocketMQ在阿里云上曾经凋谢公测近半年，目前以云服务模式收费供大家商用，并向用户承诺99.99%的可靠性，同时彻底解决了用户本人搭建MQ产品的运维复杂性问题
小标题
成熟度
Kafka在日志畛域比拟成熟
RocketMQ在阿里团体外部有大量的利用在应用，每天都产生海量的音讯，并且顺利反对了屡次天猫双十一海量音讯考验，是数据削峰填谷的利器。