Topic

主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。

Partition

分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区：

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70

一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。

Producer

生产者，消息的生产方，一般由业务系统负责产生消息。

Producer负责决定将消息发送到哪个Topic的那个Partition。

Consumer

消费者，消息的消费方，一般是后台系统负责异步消费消息。

Consumer订阅Topic，消费Topic内部的消息。

Broker

消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。

NameServer

NameServer其实不是消息中间件的概念了，一般在分布式系统中都会有一个角色作为NameServer用于服务发现，在Kafka中使用ZooKeeper来实现，在RocketMQ中单独写了NameServer服务。

Group

Group用于标志Consumer的身份，拥有相同Group名称的Consumer一般消费一类消息，且消费逻辑是相同的。

RocketMQ中Producer也需要Group标志身份，但是实际上Producer是不需要的。因为Producer之间是不相关的，Consumer之间是需要协同工作的。

这里多解释一下为什么Consumer之间是需要协同工作的。

比如启动了两个Consumer来消费订单消息，然后调用物流系统进行发货。那么在产生一条订单消息后，只能让两个Consumer中的一个来处理消息（否者就发货两次了）所以需要一个标识将这两个Consumer标记为行为一致的。另一个场景是如果一个Consumer实例宕机了，这个时候需要有行为相同的Consumer去接管它的消费任务，那么就需要一个标识来标识行为相同的Consumer。

那是不是只要行为相同的Consumer只存在一个就好了呢？是的，如果只有行为一致的Consumer，那么就不存在协同工作，也可以不需要Group，每个Consumer拥有独立的ID即可。但是实际系统是不可能的，从系统可用性和性能上都不可能（单个Consumer就有单点问题，也有性能问题，毕竟我们谈的是分布式系统）。