rocketmq架构解读

转自：https://blog.csdn.net/earthhour/article/details/78718064

1.rocketmq部署方式
　　RocketMQ 的 Broker 有三种集群部署方式： 1. 单台 Master 部署； 2. 多台 Master部署； 3. 多 Master 多 Slave 部署；采用第 3 种部署方式时， Master 和 Slave 可以采用同步复制和异步复制两种方式。

下图是第 3 种部署方式的简单图：

下面解读一下它们之间的关系：
1.1.NameServer互相独立，彼此没有通信关系，单台NameServer挂掉，不影响其他NameServer。NameServer不去连接别的机器，不会主动推消息。

1.2.单个broker（Master、Slave）与 所有NameServer 进行定时注册，以便告知NameServer自己还活着。Broker每隔30秒向所有NameServer发送心跳，心跳包含了自身的topic配置信息。NameServer每隔10秒，扫描所有还存活的broker连接，如果某个连接的最后更新时间与当前时间差值超过2分钟，则断开此连接。此外，NameServer也会断开此broker下所有与slave的连接。同时更新topic与队列的对应关系，但不会通知生产者和消费者。
Broker slave 同步或者异步从Broker master 上拷贝数据。

1.3.consumer随机与一个NameServer建立长连接，如果该NameServer断开，则从NameServer列表中查找下一个进行连接。
consumer主要从NameServer中根据topic查询broker的地址，查到就会缓存到客户端，并向提供topic服务的master、slave建立长连接，且定时向master、slave发送心跳。如果broker宕机，则NameServer会将其剔除，而consumer端的定时任务MQClientInstance.this.updateTopicRouteInfoFromNameServer每30秒执行一次，会将topic对应的broker地址拉取下来，此地址已经为slave地址了，故此时consumer会从slave上消费。 消费者与master和slave都建有连接，在不同场景有不同的消费规则。

1.4.Producer随机与一个NameServer建立长连接，每隔30秒（此处时间可配置）从NameServer获取topic的最新队列情况，这就表示如果某个broker master宕机，producer最多30秒才能感知，在这个期间，发往该broker master的消息将会失败。Producer会向提供topic服务的master建立长连接，且定时向master发送心跳。生产者与所有的master连接，但不能向slave写入。
客户端是先从NameServer寻址的，得到可用Broker的IP和端口信息，然后自己去连接broker。
（ps：我们在设计系统的时候，有一些全局使用的公用信息，可以单独独立一个模块进行专门的管理；各个子模块只需要定时向该模块更新信息即可。）

综上所述，我们可以得出NameServer在RocketMQ中所扮演的角色：

(1). NameServer 用来保存活跃的 broker 列表，包括 Master 和 Slave 。

(2). NameServer 用来保存所有 topic 和该 topic 所有队列的列表。

(3). NameServer 用来保存所有 broker 的 Filter 列表。
　　对于RocketMQ 来说，topic 的数据在每个 Master 上是对等的，没有哪个 Master 上有 topic 上的全部数据，所以对于zookeeper的Master 选举功能在Rocket中使用不到。
Broker与slave配对是通过指定相同的brokerName参数来配对，master的brokerId必须为0，slave的brokerId必须大于0，此外一个master下可以挂多个slave，同一个master下的多个slave通过指定不同的brokerId来区分。

2.RocketMQ为什么不使用ZooKeeper？
　　ZooKeeper可以提供Master选举功能，比如Kafka用来给每个分区选一个broker作为leader，但对于RocketMQ来说，topic的数据在每个Master上是对等的，没有哪个Master上有topic上的全部数据，所以这里选举leader没有意义；RockeqMQ集群中，需要有构件来处理一些通用数据，比如broker列表，broker刷新时间，虽然ZooKeeper也能存放数据，并有一致性保证，但处理数据之间的一些逻辑关系却比较麻烦，而且数据的逻辑解析操作得交给ZooKeeper客户端来做，如果有多种角色的客户端存在，自己解析多级数据确实是个麻烦事情；既然RocketMQ集群中没有用到ZooKeeper的一些重量级的功能，只是使用ZooKeeper的数据一致性和发布订阅的话，与其依赖重量级的ZooKeeper，还不如写个轻量级的NameServer，NameServer也可以集群部署，NameServer与NameServer之间无任何信息同步，只有一千多行代码的NameServer稳定性肯定高于ZooKeeper，占用的系统资源也可以忽略不计，何乐而不为？当然，这些只是本人的一点理解，具体原因当然得RocketMQ设计和开发者来说。