文章目录
前言
如果您觉得有用的话，记得给博主点个赞，评论，收藏一键三连啊，写作不易啊^ _ ^。
而且听说点赞的人每天的运气都不会太差，实在白嫖的话，那欢迎常来啊!!!
10分钟弄懂 rocketMQ 架构设计
01 rocketMQ 是什么?
简单来说， RocketMQ是由阿里捐赠给Apache的一款分布式、队列模型的开源消息中间件。
02 rocketMQ 架构组成
NameServer集群、Broker集群、Producer集群以及Consumer集群。
RocketMQ集群部署的，支持多master 模式、多master多slave异步复制模式、多 master多slave同步双写模式。
03 rocketMQ 物理部署图
04 架构设计
1)、Broker消息服务器启动时向所有NameServer注册(保持长连接并 每隔30s向NameServer报告自己还活着，若检测到Brocker宕机，从注册表中移除)。
2)、Producer(生产者)发送之前从NameServer获取Broker列表，根据负载算法获取一个Broker服务进行消息发送。
3)、Consumer消费信息。
注:NameServer路由变化不会马上通知生产者，为了降低NameServer的复杂性，通过发送端提供的容错机制保证高可用性。
04::01 NameServer路由中心
NameServer集群:其角色类似Dubbo中的Zookeeper、即路由中心，但它比Zookeeper要轻，因为集群部署的时候彼此之间互不相通，即某一时刻，NameServer服务的数据也并不会完全一样，但它不会影响消息发送，NameServer服务在RockerMQ里主要开销是在维持心跳和提供Topic-Broker的关系数据，这也是RocketMQ NameServer 的一大亮点，设计追求简单高效。
注:Broker向NameServer发心跳时， 会带上当前自己所负责的所有Topic（主题::消息的规类）信息，若Topic信息过大，同时网络信息过差时，网络传输失败，心跳失败，导致NameServer误认为Broker心跳失败。
04::01::01 NameServer逻辑图
04::01::02 路由注册
NameServer 收到Broker心跳包后更新brockerLiveTable 中的信息，特别记录心跳时间lastUpdateTime。
04::01::03 删除机制
NameServer 每隔10s扫描brockerLiveTable，检测上次收到心跳包的时间和当前时间，如果超过120s,移除路由表中与该broker相关的所有信息。
04::02 Broker
消息中转角色，负责存储消息，转发消息。
会定时将Topic(主题)信息注册到NameServer。
04::03 Producer 生产者
提供了三种方式:
- 同步(sync)
生产者向MQ发送消息时，同步等待，直到消息服务器返回发送结果。 - 异步(async)
生产者向MQ发送消息时，指定发送成功后的回调函数，然后调用消息发送API时，立即返回，消息发送者线程不堵塞，直到运行成功，发送成功或失败的回调任务在一个新的线程中执行。 - 单向(oneway)
生产者向MQ发送消息时，直接返回，不等待消息服务器结果，也不注册回调函数，即只管发，不管消除发送是否成功。
04::04 Consumer生产者
负责消费消息。
消费者以组的模式开展，一个消费组内可以包含多个消费者，每一个消费组可以订阅多个主题，消费组之间有集群模式和广播模式两种。
- 集群模式:
主题下的同一条消息只能被其中一个消费者消费。 - 广播模式:
主题下的同一条消息将被集群内的所有消费组消费一次。
消息服务器与消费者之间的消息传递方式:
- 拉模式、即消费者主动发起消息请求
- 推模式、即消息到达消费服务后，主动推送给消息消费者
RocketMQ的推模式的实现是基于拉模式，在拉模式上包装一层，即一个拉取任务完成后开始下一个拉取任务。