Kafka
Kafka早在5年前就已经非常流行。4年前用Kafka做日志缓存，输入接入缓冲，经过Kafka的数据量有100TB级别。
Kafka本身非常强壮，前提是：
1、topic不多，最好一个topic；
2、分区多个没关系，分区副本最好只有一个；
3、zookeeper只有一个节点
这样的前提下，Kafaka能支持高并发的消息数据接入。
如果副本较多就会不断的同步数据文件，性能急剧下降；
如果zk多个节点，元数据信息在zk节点中，数据量大的时候，zk不能稳定，导致节点不一致的问题。一旦不一致，kafka集群就会出现数据紊乱，数据丢失的问题。
topic比较多，topic信息也是zk来管理和更新，瓶颈还是在zk上。
阿里巴巴多年前有个叫dubbo的服务在业内出名，但是为什么用着用着内部也不用dubbo呢，因为dubbo必须依赖zookeeper，dubbo官方文档干脆说内部dubbo使用自研的注册组件，zk是个小公司生产用还行的组件，有严重性能瓶颈。
RocketMQ
RocketMQ是阿里巴巴模仿了Kafka的设计和特性，使用Java语言进行改良的消息中间件
主要改良：
1、注册中心不使用zk，而是重写了一个叫nameserver的模块，专门负责消息路由，消息管理，注册和消费
2、取消Kafka的分区机制，在RocketMQ里面对应Tag和消息队列机制，也就是说一个topic和Tag组合对应kafka的一个分区，这个组合或者分区里的消息是有序的。
3、RocketMQ完全支持顺序消费，支持事务消息功能，Kafaka要顺序消费也可以，使用一个分区就可以。
不足：
1、nameserver依然是单点，如果nameserver master挂掉需要重新选举，依然会有短暂的消息丢失。这一点和kafka用到zk的情形一样。
2、rocketMQ虽然是apache顶级项目，在IT圈里面使用的人并不多，技术生态比Kafka差远了。代码bug比Kafka多，有问题也难查。
其他方面的功能RocketMQ和Kakfa都基本相同。
RocketMQ基本用法参考：
https://www.cnblogs.com/520playboy/p/6750023.html