rocketMq和kafka的架构区别

概述

其实一直想写一篇rocketMq和kafka在架构设计上的差别，但是一直有个问题没搞明白所以迟迟没动手，今天无意中听人点播了一下似乎明白了这个问题，所以就有了这篇对比。

这篇博文主要讲清楚kafka和rocketMq的两个不同点，1、rocketMq的namesvr和kafka的zookeeper对比；2、kafka为什么比rocketMq有更大的吞吐量。如果能够讲清楚上面两个问题我觉得就已经很满足了。

最后，文章引入的参考文章里面有一些比较好的链接，有兴趣的话可以好好看看，里面其实有些地方比我讲解的更深入。

namesrv VS zk

1、我们可以对比下kafka和rocketMq在协调节点选择上的差异，kafka通过zookeeper来进行协调，而rocketMq通过自身的namesrv进行协调。

2、kafka在具备选举功能，在Kafka里面，Master/Slave的选举，有2步：第1步，先通过ZK在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。因为有了选举功能，所以kafka某个partition的master挂了，该partition对应的某个slave会升级为主对外提供服务。

3、rocketMQ不具备选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不能让一个Slave切换成Master。那么rocketMq是如何实现高可用的呢，其实很简单，rocketMq的所有broker节点的角色都是一样，上面分配的topic和对应的queue的数量也是一样的，Mq只能保证当一个broker挂了，把原本写到这个broker的请求迁移到其他broker上面，而并不是这个broker对应的slave升级为主。

4、rocketMq在协调节点的设计上显得更加轻量，用了另外一种方式解决高可用的问题，思路也是可以借鉴的。