网站建设教程费用,心悦dnf免做卡网站,省市建设类网站链接,在线生成短链接网址4.1 NameServer 的功能 NameServer 是整个消息队列中的状态服务器#xff0c;集群的各个组件通过它来了解全局的信息 。 同时#xff0c;各个角色的机器都要定期向 NameServer 上报自己的状态#xff0c;超时不上报的话#xff0c; NameServer 会认为某个机器出故障不可用了…4.1 NameServer 的功能 NameServer 是整个消息队列中的状态服务器集群的各个组件通过它来了解全局的信息 。 同时各个角色的机器都要定期向 NameServer 上报自己的状态超时不上报的话 NameServer 会认为某个机器出故障不可用了其他的组件会把这个机器从可用列表里移除。 NamServer 可以部署多个相互之间独立其他角色同时向多个 NameServer机器上报状态信息从而达到热备份的目的。 NameServer 本身是无状态的也就是说 NameServer 中的 Broker 、 Topic 等状态信息不会持久存储都是由各个角色定时上报并存储到内存中的NameServer 支持配置参数的持久化 一般用不到 。 4.1.1 集群状态的存储结构 org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager有五个变量RouteInfoManager.javahttps://gitee.com/apache/rocketmq/blob/develop/namesrv/src/main/java/org/apache/rocketmq/namesrv/routeinfo/RouteInfoManager.java /*** 这个结构的 Key 是 Topic 的名称它存储了所有 Topic的属性信息。* Value 是个 QueueData 队列 队里的长度等于这个 Topic数据存储的* Master Broker 的个数 QueueData 里存储着 Broker 的名称、读写* queue 的数量 、 同步标识等*/private final MapString/* topic */, MapString, QueueData topicQueueTable;/*** 以 BrokerName 为索引 相同名称的 Broker 可能存在多台机器 一个* Master 和多个 Slave 。 这个结构存储着一个 BrokerName 对应的属性信* 息包括所属的 Cluster 名称 一个 Master Broker 和多个 Slave Broker * 的地址信息 。*/private final MapString/* brokerName */, BrokerData brokerAddrTable;/*** 存储的是集群中 Cluster 的信息结果很简单就是一个 Cluster 名称对* 应一个由 BrokerName 组成的集合。*/private final MapString/* clusterName */, SetString/* brokerName */ clusterAddrTable;/*** 这个结构和 BrokerAddrTable 有关系但是内容完全不同这个结构的* Key 是 BrokerAddr 也就是对应着一台机器 BrokerAddrTable 中的 Key* 是 BrokerName 多个机器的 BrokerName 可以相同 。 BrokerLiveTable* 存储的内容是这台 Broker 机器的实时状态包括上次更新状态的时间戳 * NameServer 会定期检查这个时间戳 超时没有更新就认为这个 Broker 无效了* 将其从 Broker 列表里清除。*/private final MapBrokerAddrInfo/* brokerAddr */, BrokerLiveInfo brokerLiveTable;/*** FilterServer 是过滤服务器是 RocketMQ 的一种服务端过滤方式一* 个 Broker 可以有 一个或多个 FilterServer 。 这个结构的 Key 是 Broker* 的地址 Value 是和这个 Broker 关联的多个 FilterServer 的地址。*/private final MapBrokerAddrInfo/* brokerAddr */, ListString/* Filter Server */ filterServerTable; 4.1.2 状态维护逻辑 因为其他角色会主动向Name Server 上报状态所以 NameServer 的主 要逻 辑在 DefaultRequest Processor 类中根据上报消息里的请求码做相 应 的处理 更新存储的对应信息 。 此外连接断开的 事 件也 会 触发状态 更新具体逻辑在org.apache.rocketmq.namesrv.routeinfo.BrokerHousekeepingService 当 NameServer 和 Broker 的长连接断掉以后 onChannelDestroy 函数会被调用把这个 Broker 的信息清理出去 。 NameServer 还有定时检查时间戳的逻辑 Broker 向 NameServer 发送的心跳会更新时间戳 当 NameServer 检查 到时间戳长时间没有更新后便会触发清理逻辑 。
org.apache.rocketmq.namesrv.NamesrvController 每5s检查一次 4.2 各个角色间的交互流程 4.2.1 交互流程源码分析 创建 Topic 的代码 是 在 org.apache.rocketmq.tools.command.topic 里的UpdateTopicSubCommand 类中创建 Topic 的命令 是 updateTopic
UpdateTopicSubCommand.javahttps://gitee.com/apache/rocketmq/blob/develop/tools/src/main/java/org/apache/rocketmq/tools/command/topic/UpdateTopicSubCommand.java org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand#execute 调用org.apache.rocketmq.tools.admin.DefaultMQAdminExt#createAndUpdateTopicConfig
是向 NameServer 发 送注 册 信 息 NameServer 完 成创 建Topic 的逻辑后其他客户端才能发现新增 的 Topic 相关逻辑在org.apache.rocketmq.namesrv. routeinfo.RouteInfoManager#registerBroker首先更新 Broker 信息然后对每个 Master 角色的 Broker 创建一个QueueData 对象。 如果是新建 Topic 就是添加 QueueData 对象如果是修改Topic 就是把旧的 QueueData 删除 加入新的 QueueData 。 4.2.2 为何不用 ZooKeeper RocketMQ 的架构设计决定了它不需要进行 Master 选举用不到这些复杂的功能只需要一个轻量级的元数据服务器就足够了 。 5 张图告诉你 RocketMQ 为什么不使用 Zookeeper 做注册中心 - 腾讯云开发者社区-腾讯云 (tencent.com)https://cloud.tencent.com/developer/article/2118883
4.3 底层通信机制 4.3.1 Remoting 模块 RocketMQ 的通信相关代码在 Remoting 模块里先来看看主要类结构 NettyRemotingClient、NettyRemotingServer而 且 都继承了NettyRemoting-Abstract 类 。通过上面的封装 RocketMQ 各个模块间的通信 可以通过发送统一格式的自定义消息 RemotingCommand 来完成 各个模块间的通信实现简洁明了 。 比如 NameServer 模 块中 NameServerController 有 一 个 remotingServer 变量 NameServer 在启动时初始化各个变量 然后启 动 remotingServer 即可剩下 NameServer 要 做的 是专心实现处理 RemotingCommand 的逻辑。 org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#processRequest 4.3.2 协议设计和编解码 RocketMQ 自己定义了一个通信协议使得模块间传输的二进制消息和有意义 的内 容之间互相转换。 1 第一部分是大端 4 个字节整数值等于第二、三、 四部分长度的总和 2 第二部分是大端 4 个字节整数值等于第三部分的长度 3 第三部分是通过 Json 序列化的数据 4 第四部分是通过应用自定义二进制序列化的数据。 消息的解码过程在 RemotingCommand 的 decode 函数里org.apache.rocketmq.remoting.protocol.RemotingCommand#decode(io.netty.buffer.ByteBuf) org.apache.rocketmq.remoting.protocol.RemotingCommand#encode 4.3.3 Netty 库 RocketMQ 是基于 Netty 库来完成 RemotingServer 和 RemotingClient 具体的通信实现的 Netty 是个事件驱动的网络编程框架它屏蔽了 Java Socket 、 NIO等复杂细节用户只需用好 Netty 就可以实现一个“ 网络编程专家并发编程专家”水平的 Server 、 Client 网络程序 。 应用 Netty 有一定的门槛需要了解它的 EventLoopGroup 、 Channel 、 Handler 模型以及各种具体的配置。 RocketMQ利用 Netty 实现的通信类是 NettyRemotingServer 和 NettyRemotingClient 用户也可以参考这两个类的实现来学习使用 Netty 。
