一、RocketMQ部署的组件

RocketMQ是啥就不多说了，一个基于主题的订阅发布机制的消息中间。下面就是我们部署时的架构，NameServer和Broker需要部署在服务器上，对于消费者和生产者则是我们在自己的程序里启动，去push/pull消息。

消息生产者(Producer)发送到某一主题(Topic)的消息到消息服务器(Broker)，Broker负责消息的持久化存储，消息消费者(Consumer)订阅需要用的Topic，Broker根据订阅信息把消息推送给消费者(推送模式)或者消费者主动向Broker拉取消息(拉模式)，这样便实现了生产者和消费者之间的解耦。这也是我们使用消息中间件的一大原因之一。

二、组件说明

2.1 NameServer路由注册中心

RocketMQ摒弃了Zookeeper作为其注册中心，而是自己实现了一个NameServer来管理路由、服务注册和服务发现机制。NameServer的高可用性是通过部署多态NameServer组成集群，但集群中各NameServer批次之间互不通信。NameServer服务器之间在某一时刻的数据并不会完全相同，但对消息发送不会造成重大影响，无非就是短暂造成消息发送不均衡，所以NameServer集群中的数据一致性是采用了最终一致性。

2.2 Broker消息服务器

消息服务器，负责消息的持久化存储。从上图可见，其分为两种角色：Master和Slave。如上图的两主两从的架构。Master Broker负责读写功能，Slave Broker作为一个备份，当Master Broker存在压力时，可以从Slave Broker读取信息。所有的Broker(Master和Slave)每个30秒就向NameServer集群发送心跳包，主要包含的信息当前Broker上的Topic路由信息和自身Broker信息。

2.3 Client：Producer(消息生产者)和Consumer(消息消费者)

2.3.1 Producer

RocketMQ发送消息3种方式：同步、异步和单向

同步发送： 生产者向RocketMQ发送消息之后，同步等待，知道消息服务器(Broker)返回发送结果。

异步发送： 生产者向RocketMQ发送消息之后，指定消息发送成功后需要执行的回调函数，调用消息发送的API之后立即返回，生产者线程不阻塞，直至运行结束。消息发送成功或失败的回调任务在一个新的线程中执行。

单向发送： 生产者向RocketMQ发送消息之后，直接返回，不等待消息服务器(Broker)的返回结果，也不注册回调函数。也就是不管消息是否成功存储在消息服务器(Broker)和消息是否成功被消费。

2.3.2 Consumer

RocketMQ的消息消费以组的模式展开，一个消费组可以包含多个消费者，每个消费组可以订阅多个主题，消费组之间有集群模式和广播模式两种消费模式。

**集群模式：**在当前主题下的同一条消息只允许被其中一个消费者消费。

**广播模式：**在当前主题下的同一条消息将被集群内所有的消费者消费一次。

消息服务器(Broker)和消费者之间的消息传递方式有两种：拉模式和推模式。

拉模式： 是消费端发起请求，主动向消息服务器(Broker)拉取消息。

推模式： 消息到达消息服务器之后，推送给消费者。推模式基于拉模式实现，在拉模式上包装一层，一个拉取任务完成后开始下一个拉取任务。

消息拉模式主要是由客户端手动调用消息拉取API，而消息推模式是消息服务器主动将消息推送到消息消费端。关于消息队列的负载均衡机制遵循一个通用的思想：一个消息队列同一时间只允许被一个消费者消费，一个消费者可以消费多个消息队列。

RocketMQ支持局部顺序消费，也就是保证同一消息队列上的消息按顺序消费。不支持消息全局顺序消费，如果要实现某一个Topic的全局顺序消息消费，可以将该主题的队列数设置为1，这样便牺牲高可用性。

三、小总结

关于RocketMQ的组件就介绍到这里了，后续会不断展开关于RocketMQ的原理和实战用法。下一篇将从NameServer开始。