RocketMq-粪发涂墙1.0

角色	说明
Producer	生产者，用于将消息发送到RocketMQ，生产者本身既可以是生成消息，也可以对外提供接口，由外部来调用接口，再由生产者将受到的消息发送给MQ。
Consumer	消费者，从Broker拉取消息进行消费。从应用角度来说有两类消费者： PullConsumer：主动拉取消息，一旦拉取到消息，应用的消费进程进行初始化 PushConsumer：封装消息拉取，消费进程和内部
Broker	RocketMQ服务器，也是整个服务的核心，它实现了消息的存储、拉取功能。它通常以集群方式启动，并可配置主从，每个broker上提供对指定topic的服务。理解了broker的原理以及它和其他服务交互的过程，也就命令消息中间件的原理，其实都大同小异。它具有2中角色 Master：能写、能读 Slave：只能读，不能写
Topic	消息的主题，由用于定义并在服务端配置，消费者可以按照主题进行订阅，也就是消息分类，通常一个应用一个Topic
Message	在生产者、消费者、服务器之间传递的消息，一个message必须属于一个Topic
Namesrv	一个无状态的名称服务，可以集群部署，每一个broker启动的时候都会向名称服务器注册，主要是接收broker的注册（broker每十秒就会向所有名称服务器发送心跳请求，同时注册topic信息到名称服务器），接收客户端的路由请求并返回路由信息，你可以理解为服务自动发现，就是相当于zookeeper在dubbo框架中的作用。 生产者发消息时会根据Topic向名称服务器获取到指定broker的路由信息 消费者根据Topic到名称服务器获取该Topic到broker的路由信息
Group	组名，一类消费者或者生产者的集合名称。 消费者组，消费相同Topic内容的消费者，可以并行消费Topic中Partition中的消息。 生产者组，生产相同Topic内容的生产者
Offset	偏移量，消费者拉取消息时需要知道上一次消费到了什么位置，这一次从哪里开始。
Partition	分区，Topic物理上的分组，一个Topic可以分为多个分区，每个分区是一个有序的队列。分区中的每条消息都会给分配一个有序的ID，也就是偏移量。 分区的目的： 减缓日志文件占用磁盘空间，消息需要持久化到文件，分区可以将消息粒度细分，每个分区可以存放在不同的磁盘空间中 不同消费者同时消费分区中的数据，一个分区仅由一个消费者组中的消费者消费，1个消费者可以同时消费多个分区。 可以实现负载均衡，如果同一个Topic的消息都放在同一个Broker上，那消费的时候同一个Topic的消费者都去同一个Broker上消费，这样会带来压力，如果通过分区放在不同Broker上，这样就可以到不同的Broker上消费，当然同一个ID的消息只能存在一个分区上。你可以想象A这个topic的消息有10个那么每个消息有1个ID，如果分布10个消息分布在不同的分区上，比如3个，那就形成3-3-4，消费者去消费的时候消费10条消息时通过3个分区完成这样就提高了吞吐量。 Topic是消息的逻辑队列，分区是物理队列。可以通过配置文件来设置topic的默认分区数量，也可以在新建立topic的时候指定。建议分区数量和消费者数量一致，因为消费者数量多，多出来的不会去消费消息的，因为一个队列只能被一个消费者消费。如果消费者数量少则消费者就会比较繁忙。
Tag	用于对消息进行过滤，理解文件message的子主题，同一业务不同目的的message可以用相同的topic但是可以用不同的tag来区分，在队列中tag在消息的数据结构中被 转换为一个8byte的hashcode，这样节省空间。过滤分两步： 在Broker端进行Message Tag对比，先遍历Consume Queue，如果存储的Message tag与订阅的tag不符合就跳过，符合则传输给Consumer，在队列中继续比对hashcode Consumer收到消息后，对比真实的Message Tag字符串，而不是Hashcode，这样避免HASH冲突。
key	消息的KEY字段是为了唯一表示消息的，方便查问题，不是说必须设置，只是说设置为了方便开发和运维定位问题，这个KEY可以是订单ID等。

来源：https://www.cnblogs.com/longxok/p/11315575.html