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

分布式消息服务 Kafka 是一个高吞吐、高可用的消息中间件服务，适用于构建实时数据管道、流式数据处理、第三方解耦、流量削峰去谷等场景，具有大规模、高可靠、高并发访问、可扩展且完全托管的特点，是分布式应用上云必不可少的重要组件。

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这个概念&#