RocketMQ-概念-角色分析

---

【RocketMQ学习目录】

---

1.介绍

• 简介
  经过多次天猫双十一的考验
  支持 亿级别的消息堆积
  采用零拷贝的原理，顺序写盘随机度
  底层通信采用的Netty
  自写更轻量级的NameServert替代Zookeper
  支持 消息重试机制，存在时间间隔与重试次数可配置
  支持 同步消息、异步消息、顺序消息、延迟消息、的可靠投递
  支持 分布式事务，与主从模式的高可用
  支持 消息零丢失(同步双写+同步刷盘)
  支持 广播消息
  支持 基于SQL92的属性过滤器表达式
  支持 服务器触发的重新交付
  支持 按照时间戳和偏移量，进行消息追溯
  支持 Web端图形化界面管理
  社区活跃度高
• 图来源于官网
  http://rocketmq.apache.org/docs/motivation/

2.概念图

3.角色分析

1.Message 消息

• 服务间进行通信的载体，存在以下属性

• Topic 主题
  要传递的消息。必须包含一个主题，理解为消息所属分类名称。

• Tag 标签
  消息可以具有标签和额外的键值对。
  标签将有助于保持代码整洁和一致。
  标签可以简化RocketMQ的查询操作。

• Message Queue 消息队列
  消息队列=主题+主题内的消息。

2.Broker 与 NamerServer 消息处理服务 与 服务寻址

• Broker 消息处理服务
  Broker 将生产者发过来的消息，进行存储, 是RocketMQ系统的主要组成部分
  Broker 处理来自消费者的拉取请求
  Broker 存储与消息相关的元数据，包括使用者组，使用者进度偏移量和主题/队列信息。

• NamerServer 提供对于Broker的注册与寻址
  生产者/消费者 通过 NamerServer 找到 Broker,进行消息的处理

3.Producer 生产者

• Producer 生产者
  生产者角色，负责生产消息，消息多数来源于业务服务
  RocketMQ 提供了多种发送范例：同步，异步和单向

• Producer Group 生产者组
  具有相同角色的生产者被分成一组。
  当原始生产者在处理事务过程中崩溃，则broker可以联系同一组内的其他产者实例，提交或回滚事务。
  每个生产者组只允许一个实例，以避免不必要的生产者实例初始化。

4.Consumer 消费者

消费者从 broker 那里获取消息，并将其输入到应用程序中。
从用户应用的角度来看，提供了两种类型的消费模式

• Pull Consumer 主动消费
  消费者主动从 Broker 那里拉取消息，进行处理。

• Push Consumer 被动消费
  消费者监听，Broker的回调接口，被动接收消息，然后进行处理。

• Consumer Group 消费者组
  角色完全相同的消费者被分在一起，命名为Consumer Group。
  消费者组实现负载平衡和容错
  注意：消费者组内的实例，必须都订阅相同的主题。

撒 花 ❀❀❀❀❀❀❀❀❀❀❀❀