基于电商场景的高并发RocketMQ实战-NameServer内核原理剖析、Broker 主从架构与集群模式原理分析


【11来了】文章导读地址:点击查看文章导读!

基于电商场景的高并发 RocketMQ 实战

Rocket 架构分析

NameServer 内核原理剖析

NameServer 是可以集群部署的,但是集群中的每台 NameServer 之间 不会进行通信,这样的好处就是 NameServer 集群中每个节点都是对等的,其中一台挂了之后,对集群不会有影响

Broker 在启动之后,会想 NameServer 集 群中的每个 NameServer 中都会注册自己的信息

Broker 每隔 30s 会想 NameServer 中发送心跳,来让 NameServer 感知到 Broker 的存活状态

在 NameServer 中有一个后台线程,会每隔 10s 去检查是否有 Broker 在 120s 内都没有发送心跳,如果有,就将该 Broker 从存活列表中剔除掉!

Broker 主从架构与集群模式原理分析

在 Broker 集群中,生产者需要向 Broker 中写数据的话,先从 NameServer 中进行一个 Broker 列表的查询,之后再通过 负载均衡 去选择一个 Broker 进行消息的存储

Broker 的主从关系通过将 Broker 的 name 设置相同,brokerId 是 0 的话代表 Broker 是主节点的 ,brokerId 不是 0 的话代表 Broker 从节点的,Broker 的主从架构如下图:

基于电商场景的高并发RocketMQ实战-NameServer内核原理剖析、Broker 主从架构与集群模式原理分析_第1张图片

关于消息中 Topic 的概念:

在生产者向 Broker 中发送消息的话,是指定了一个 Topic 的,那么 Topic 下是有一个 队列 的概念的

Topic 会在每个 Broker 分组里创建 4 个 write queue 和 4 个 read queue

那么生产者写入消息时,先根据 Topic 找到需要写入的 write queue,找到该 queue 所在的 Broker 进行写入,如下图:

基于电商场景的高并发RocketMQ实战-NameServer内核原理剖析、Broker 主从架构与集群模式原理分析_第2张图片

你可能感兴趣的:(RocketMQ,java-rocketmq,rocketmq,架构)