底子篇-根本架构

1.NameServer

1.1 概述

NameServer是一个无状态的服务器，类似于ZooKeeper，但比ZooKeeper轻量。
无状态意味着：

• 新的NameServer可以在不与现有NameServer集群同步数据的环境下，轻松加入到该集群中，从而实现了NameServer的水平扩容。
  
• NameServer集群中的任何一台NameServer服务器宕机之后，整个系统都不会丢失任何信息，并且，针对于该故障机器，还可以进行简朴的替换和重启。
  
• 用户端可以自由发送信息到NameServer集群中的任何一台NameServer服务器，而无需担心该服务器是否持有最全最新的数据。
  

1.2 功能

• **健康检查**：NameServer通过长毗连的心跳机制，定期检查每个Broker的健康状态。
  
• **提供Topic的路由信息**：NameServer将存储全部Broker的全部Topic的路由信息，以便在生产者和消费者哀求时可以或许及时提供所需的路由信息。
  

2.Broker

2.1 概述

Broker负责消息的**存储**和**转发**。
单个Broker会与所有NameServer保持长毗连和心跳，并定时将Topic信息同步给所有NameServer。
2.2 处理消息的流程

• 消息吸收：Broker在吸收到一个生产者发来的消息后，会先将其写入CommitLog文件中去。
  
• 消息分发：Broker将会启动一个线程，单独负责将CommitLog新的内容写入到IndexFile和ConsumerQueue中去。
  
• 消息投递：消费者通过PullMessageProcessor类拉取ConsumerQueue中的消息数据，然后进行消息的处理。
  

3.Producer

3.1 概述

业务端可以负载均衡的模式发送消息到Broker集群，可由用户进行分布式摆设。
3.2 消息的生产方式

• **同步发送**：发送一条消息后必须在吸收方发回相应之后才气继承发送下一条消息。
  
  
  
• **异步发送**：发送一条消息后无需等候吸收方发回相应便可继承发送下一条消息。
  
  
  
• **单向发送**：只管发送消息给吸收方而不管吸收方的回应，这种方式不能注册回调函数。该方式一般用于耗时短且对可靠性要求不高的场景，如日志的收集。
  
  
  

4.Consumer

3.1 概述

负责消息的消费处理。
3.2 消息的消费方式

• **pull**：消费者将主动从Broker拉取消息，一旦拉取到新的消息过来，就立即启动消息消费过程。
  
  
  
• **push**：消费端通过提前注册好一个及时监听新消息到了的回调函数，从而在新消息到来时，主动实行相应的处理逻辑(一般处理逻辑都写在这个回调函数中)。(从实现方面来看，该方式还是与pull方式一样)
  
  
  

3.3 消息的消费模式

• **集群消费(默认)**：在消费同一个Topic下的消息时，RocketMQ会将新产生的多条消息分别投递给同一消费者组中的不同消费者，也就是说，每条消息只会被所投中的消费者进行一次性消费，不会被其他消费者消费了。该方式适合消费的负载均衡、大数据的分布式处理等场景。(注：该方式将会重投消费失败的消息，但不保证消息将被再次投递到同一台机器上去)
  
  
  
• **广播消费**：在消费同一个Topic下的消息时，RocketMQ会将新产生的多条消息分别投递给同一消费者组中的每一个消费者，也就是说，每条消息都会被同消费者组中的全部消费者消费到。该方式适合关照通告、分布式系统的多节点的配置同步或数据变动等场景。(注：该方式不会重投消费失败的消息)(注2：在同一消费者组中，若出现不同消费者之间配置了不同消费模式的环境，则整个消费者组全部采取广播消费模式)
  
  
  

---

参考文档

消息队列口试题之RocketMQ篇，23道RocketMQ八股文
RocketMQ源码-broker 消息吸收流程(写入commitLog)
消费者负载均衡

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。