共计 2497 个字符，预计需要花费 7 分钟才能阅读完成。
为了不便大家更好的选型，小编整顿一份 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 在阿里团体外部有大量的利用在应用，每天都产生海量的音讯，并且顺利反对了屡次天猫双十一海量音讯考验，是数据削峰填谷的利器。
