RocketMQ和Kafka的对比
（1） 适用场景
Kafka适合日志处理；
RocketMQ适合业务处理。
结论：平手，根据具体业务定夺。
（2） 性能
Kafka单机写入 TPS 号称在百万条/秒；
RocketMQ 大约在10万条/秒。
结论：追求性能的话，Kafka单机性能更高。
（3） 可靠性
RocketMQ支持异步/同步刷盘;异步/同步Replication；
Kafka使用异步刷盘方式，异步Replication。
结论：RocketMQ所支持的同步方式提升了数据的可靠性。
（4） 实时性
均支持pull长轮询，RocketMQ消息实时性更好
结论：RocketMQ 胜出。
（5） 支持的队列数
Kafka单机超过64个队列/分区，消息发送性能降低严重；
RocketMQ 单机支持最高5万个队列，性能稳定
结论：长远来看，RocketMQ 胜出，这也是适合业务处理的原因之一
（6） 消息顺序性
Kafka 某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序；
RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，
发送消息会失败，但是不会乱序；
结论：RocketMQ 胜出
（7）消费失败重试机制
Kafka消费失败不支持重试
RocketMQ消费失败支持定时重试，每次重试间隔时间顺延。
（8）定时/延时消息
Kafka不支持定时消息；
RocketMQ支持定时消息
（9）分布式事务消息
Kafka不支持分布式事务消息；
阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
（10）消息查询机制
Kafka不支持消息查询
RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息
（11）消息回溯
Kafka理论上可以按照Offset来回溯消息
RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息
Broker差异
主从差异: kafka的master/slave是基于partition维度的，而rocketmq是基于broker维度的；kafka的master/slave是可以切换的，而rocketmq不行，当rocketmq的master宕机时，读能被路由到slave上，但写会被路由到此topic的其他broker上。
刷盘：
rocketmq支持同步刷盘，也就是每次消息都等刷入磁盘后再返回，保证消息不丢失，但对吞吐量稍有影响。一般在主从结构下，选择异步双写策略是比较可靠的选择。
消息查询：
rocketmq支持消息查询，除了queue的offset外，还支持自定义key。rocketmq对offset和key都做了索引，均是独立的索引文件。
消费失败重试与延迟消费：
rocketmq针对每个topic都定义了延迟队列，当消息消费失败时，会发回给broker存入延迟队列中，每个消费者在启动时默认订阅延迟队列，这样消费失败的消息在一段时候后又能够重新消费。延迟时间适合延迟级别一一对应的，延迟时间是随失败次数逐渐增加的，最后一次间隔2小时。当然发送消息是也可以指定延迟级别，这样就能主动设置延迟消费，在一些特定场景下还是有作用的。
数据写入：
kafka每个partition独占一个目录，每个partition均有各自的数据文件.log；而rocketmq是每个topic共享一个数据文件commitlog因为kafka的topic一般有多个partition，所以kafka的数据写入熟读比rocketmq高出一个量级。但超过一定数量的文件同时写入，会导致原先的顺序写转为随机写，性能急剧下降，所以kafka的分区数量是有限制的。
服务治理：
kafka用zookeeper来做服务发现和治理，broker和consumer都会向其注册自身信息，同时订阅相应的znode，这样当有broker或者consumer宕机时能立刻感知，做相应的调整；而rocketmq用自定义的nameServer做服务发现和治理，其实时性差点，比如如果broker宕机，producer和consumer不会实时感知到，需要等到下次更新broker集群时(最长30S)才能做相应调整，服务有个不可用的窗口期，但数据不会丢失，且能保证一致性。但是某个consumer宕机，broker会实时反馈给其他consumer，立即触发负载均衡，这样能一定程度上保证消息消费的实时性。
Producer差异
发送方式：
kafka默认使用异步发送的形式，有一个memory buffer暂存消息，同时会将多个消息整合成一个数据包发送，这样能提高吞吐量，但对消息的实效有些影响；rocketmq可选择使用同步或者异步发送。
发送响应：
kafka的发送ack支持三种设置：消息存进memory buffer就返回；等到leader收到消息返回，等到leader和isr的follower都收到消息返回，当然kafka都是异步刷盘。rocketmq都需要等broker的响应确认，有同步刷盘，异步刷盘，同步双写，异步双写等策略，相比于kafka多了一个同步刷盘。
Consumer差异
消息过滤:
rocketmq的queue和kafka的partition对应，但rocketmq的topic还能更加细分，可对消息加tag，同时订阅时也可指定特定的tag来对消息做更进一步的过滤。或者向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。
有序消息：
rocketmq支持全局有序和局部有序，kafka也支持有序消息，但是如果某个broker宕机了，就不能在保证有序了。
消费确认：
rocketmq仅支持手动确认，也就是消费完一条消息ack+1，会定期向broker同步消费进度，或者在下一次pull时附带上offset。kafka支持定时确认，拉取到消息自动确认和手动确认，offset存在zookeeper上。
消费并行度：
kafka的消费者默认是单线程的，一个Consumer可以订阅一个或者多个Partition，一个Partition同一时间只能被一个消费者消费，也就是有多少个Partition就最多有多少个线程同时消费。rocketmq消费者分有序消费模式和并发消费模式，有序模式下，一个消费者也只存在一个线程消费；并发模式下，每次拉取的消息按consumeMessageBatchMaxSize(默认1)拆分后分配给消费者线程池，消费者线程池min=20,max=64。也就是每个queue的并罚度在20-64之间，一个topic有多个queue就相乘。所以rocketmq的并发度比Kafka高出一个量级。
事务消息：
rocketmq指定一定程度上的事务消息，当前开源版本删除了事务消息回查功能，事务机制稍微变得没有这么可靠了，不过阿里云的rocketmq支持可靠的事务消息；kafka不支持分布式事务消息。
