概述
这篇博文主要讲清楚kafka和rocketMq的两个不同点，1、rocketMq的namesvr和kafka的zookeeper对比；2、kafka为什么比rocketMq有更大的吞吐量。如果能够讲清楚上面两个问题我觉得就已经很满足了。
最后，文章引入的参考文章里面有一些比较好的链接，有兴趣的话可以好好看看，里面其实有些地方比我讲解的更深入。
namesrv VS zk
1：我们可以对比下kafka和roketMq在协调节点选择上的差异，
- kafka：是通过zookeeper来进行协调
- rocketMq：是通过自身的namesrv进行调节的
2：kafka具备选举功能，在kafka里面，master/slave选举有2步
- 先通过zk在所有机器中，选举出一个kafkaController；
- 在由这个controller决定每个partition的master是谁。因为有了选举功能，所以kafka某个partition的master挂了，该partition对应的某个slave就会升级为master，对外提供服务。
3：rocketMq不具备选举，master/slave的角色是固定的，当一个master挂了之后，你可以写到其他master上，但不能让一个slave切换成master。那么rocketMq是如何实现高可用的呢，其实很简单，rocketMq的所有broker节点的绝对都是一样的，上面分配的topic和对应的queue的数量也是一致的，Mq只能保证当一个broker挂了，把原本写到这个broker的请求迁移到其他broker上面，而并不是这个broker对应的slave升级为master。
4：rocketMq在协调节点的设计明显更加轻量，用了另外一种方式解决高可用问题，思路也是可以借鉴的。
关于吞吐量
1、首先说明下面的几张图片来自于互联网共享，也就是我后面参考文章里面的列出的文章。
2、kafka在消息存储过程中会根据topic和partition的数量创建物理文件，也就是说我们创建一个topic并指定了3个partition，那么就会有3个物理文件目录，也就说说partition的数量和对应的物理文件是一一对应的。
3、rocketMq在消息存储方式就一个物流问题，也就说传说中的commitLog，rocketMq的queue的数量其实是在consumeQueue里面体现的，在真正存储消息的commitLog其实就只有一个物理文件。
4、kafka的多文件并发写入 VS rocketMq的单文件写入，性能差异kafka完胜可想而知。
5、kafka的大量文件存储会导致一个问题，也就说在partition特别多的时候，磁盘的访问会发生很大的瓶颈，毕竟单个文件看着是append操作，但是多个文件之间必然会导致磁盘的寻道。
参考文章
分布式消息队列RocketMQ与Kafka架构上的巨大差异之1 – 为什么RocketMQ要去除ZK依赖？
分布式消息队列RocketMQ与Kafka架构上的巨大差异之2 – CommitLog与ConsumeQueue
Kafka vs RocketMQ—— Topic数量对单机性能的影响