分布式消息队列RocketMQ与Kafka架构上的巨大差异

原文来自于CSDN【travi】

在讲过几次kafka以后得到不错的反响，所以这篇文章，也是继续讲一讲kafka学习，给大家一个不错的反应

我们知道，在早期的RocketMQ版本中，是有依赖ZK的。而现在的版本中，是去掉了对ZK的依赖，转而使用自己开发的NameSrv。

并且这个NameSrv是无状态的，你可以随意的部署多台，其代码也非常简单，非常轻量。

那不禁要问了：ZooKeeper是业界用来管理集群的一个非常常用的中间件，比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子，自己做集群的管理呢？纯粹就是再做一个Zookeeper吗？

本篇试图通过一个架构上的巨大差异，来阐述为什么RocketMQ可以去掉ZK。

Kafka的架构拓扑图

我们知道，在Kafka中，是1个topic有多个partition，每个partition有1个master + 多个slave。对应如下图所示：

注意：这里只有3台机器(b0,b1,b2)，每台机器既是Master，也是Slave。具体来说，比如机器b0，对于partition0来说，它可能是Master；对应partition1来说，它可能又是Slave。

RocketMQ的架构拓扑图

不同于Kafka里面，一台机器同时是Master和Slave。在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置里面，就定死了。其架构拓扑图如下：

在这里，RocketMQ里面queue这个概念，就对应Kafka里面partition。

有3个Master, 6个Slave，那对应到物理上面，就是3+6，得9台机器！！！而不是上面像Kafka一样，3台机器。

Master/Slave/Broker概念上的差异

通过上面2张图，我们已经可以直观看出2者的巨大差异。反映到概念上，虽然2者都有Master/Slave/Broker这3个概念，但其含义是不一样的。

Master/Slave概念差异

Kafka: Master/Slave是个逻辑概念，1台机器，同时具有Master角色和Slave角色。

RocketMQ: Master/Slave是个物理概念，1台机器，只能是Master或者Slave。在集群初始配置的时候，指定死的。其中Master的broker id = 0，Slave的broker id > 0。

Broker概念差异

Kafka: Broker是个物理概念，1个broker就对应1台机器。

RocketMQ：Broker是个逻辑概念，1个broker = 1个master + 多个slave。所以才有master broker, slave broker这样的概念。

那这里，master和slave是如何配对的呢？ 答案是通过broker name。具有同1个broker name的master和slave进行配对。

具体到配置里面，如下：

//机器1的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
1
2
3
4
5
6
7
8
9
//机器2的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
1
2
3
4
5
6
7
8
//机器3的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=2
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
1
2
3
4
5
6
7
8