RocketMQ是一个消息中间件而Kafka最早是做日志处理的,它们的产生的出发点不一样，设计的时候解决问题的目标也是不一样的。
​

每种消息中间件设计的时候是解决某一种问题的。
​

对于程序来说我们使用消息中间件更关心的是消息的吞吐量、消息的可靠性、消息的性能、消息的可扩展性、消息的失败重试、事务消息等等。我们程序员更关心应用层面的东西。
​

而Kafka日志处理是允许消息丢失，也可以允许消息堆积的。
​

在每年的双十一当天,整个阿里巴巴集团通过RocketMQ流转的线上消息达到了万亿级,峰值TPS达到了5600万.
​

特性

经历过双十一考验，性能没啥太大的问题。
集群，集群代表扩展能力和负载均衡。
持久化（零拷贝/磁盘顺序存储/页缓存）
事务消息
底层通讯是Netty
NameServer（类似Zookeeper的一个服务寻址和协调）,为什么用NameServer,原因是因为Zookeeper的大量的写性能不是很高的.
​

RocketMQ特点

  1. 亿级消息的堆积能力，单个队列中的百万级消息的累积容量。
  2. 高可用性：Broker服务器支持多Master多Slave的同步双写以及Master多Slave的异步复制模式，其中同步双写可保证消息不丢失。
  3. 高可靠性：生产者将消息发送到Broker端有三种方式，同步、异步和单向，其中同步和异步都可以保证消息成功的成功发送。Broker在对于消息刷盘有两种策略：同步刷盘和异步刷盘，其中同步刷盘可以保证消息成功的存储到磁盘中。消费者的消费模式也有集群消费和广播消费两种，默认集群消费，如果集群模式中消费者挂了，一个组里的其他消费者会接替其消费。综上所述，是高可靠的。
  4. 支持分布式事务消息：这里是采用半消息确认和消息回查机制来保证分布式事务消息的
  5. 支持消息过滤：建议采用消费者业务端的tag过滤
  6. 支持顺序消息：消息在Broker中是采用队列的FIFO模式存储的，也就是发送是顺序的，只要保证消费的顺序性即可。
  7. 支持定时消息和延迟消息：Broker中由定时消息的机制，消息发送到Broker中，不会立即被Consumer消费，会等到一定的时间才被消费。延迟消息也是一样，延迟一定时间之后才会被Consumer消费。