1.RocketMQ集群搭建
1.1各角色介绍
mqGroup.png
-
角色
- NameServer:Broker的管理者。Broker自己去上报NameServer自己的存在
- Broker：消息的存储者。消息生产者把消息发送到broker
- Producer：消息的生产者
- Consumer：消息的消费者
- Topic：区分消息的种类，一个发送者可以发送消息给以一个或多个Topic；一个消息的接受者可以订阅一个或者多个Topic消息
- Message Queue：相当于Topic的分区；用于并行发送和接收消息
-
流程
- Producer先去向NameServer询问，应该将消息发给哪个Broker，再将消息发送是给对应的Broker
- Consumer向NameServer询问，应该去哪个Broker消费消息
1.2集群搭建方式
1.2.1集群特点
- NameServer：无状态的。因为每个Broker都会给NameServer上报自己的存在，所以多个NameServer无需互相同步。只需要同时部署多个NameServer即可
- Producer：也没有数据的同步，与NameServer集群其中一个节点（随机选择）建立长连接，定期获取Topic路由信息。与对应Topic信息的Master建立长连接，定时发送心跳。
- Consumer：没有数据同步。与NameServer集群其中一个节点（随机选择）建立长连接，定期获取Topic路由信息。并向对应Master、Slave建立长连接，定时发送心跳。可以从主从订阅消息
- Broker：区分了主从节点
- 主节点：主要处理写进消息操作 BrokerId：0
- 从节点：主要处理读取消息操作 BrokerId:非0
- NameServer通过BrokerName确定是否一组。同一组中，通过BrokerId区分主从
- 一个主节点可以包含多个从节点 ，但一个从节点只能对应一个主节点
1.2.2集群模式
- 单Master
风险较大，一旦Broker宕机会导致整个服务不可用 - 多Master
- 优点：配置简单，单个宕机不影响应用。磁盘配置为RAID10时，即时宕机消息也不会丢失
- 缺点：单台宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性受到影响
- 多Master多Slave（异步）
多对主从，HA采用异步复制方式，主备有短暂消息延迟。- 优点：即使磁盘损坏，消息丢失的非常少，且实时性不会受影响。Master宕机后，可以从Slave消费。性能与多Master一样
- 缺点：宕机，磁盘损坏情况下会丢失少量消息
- 多Master多Slave（同步）
HA采用同步双写：只有主备都写成功，才会向应用返回成功- 优点：数据与服务无单点故障，宕机下消息无延迟
- 缺点：性能比异步复制模式略低，主节点宕机后，备机不能自动切换为主机
1.3双主双从集群搭建
1.3.1总体架构
masterGroup.png
1.3.2集群工作流程
- 启动NameServer，NameServer起来后监听端口，等待Broker，Producer、Consumer连上来，相当于一个路由控制中心
- Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息（IP+端口等）以及存储所有Topic信息。注册成功后，NamseSever集群中就有Topic跟Broker的映射
- 收发消息前，先创建Topic，创建Topic时需指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
- Producer发送消息，启动时先跟NameServer集群中的一台保持长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在Broker建立长连接从而向Broker发消息
- Consumer与Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息
1.4mqadmin管理工具
1.5集群监控平台搭建
2.消息发送样例
- 消息生产者步骤分析
- 创建消息生产者Producer，并制定生产者组名
- 指定NameServer地址
- 启动Producer
- 创建消息对象，指定主题Topic、Tag和消息体
- 发送消息
- 关闭生产者Producer
- 消息消费者步骤分析
- 创建消费者Consumer，制定消费者组名
- 指定NameServer地址
- 订阅主题Topic和Tag
- 设置回调函数，处理消息
- 启动消费者Consumer
2.1 基本样例
2.1.1 同步消息
2.1.2 异步消息
2.1.3 单向消息
2.1.4 消费消息
- 负载均衡模式
默认。多个消费者共同承担消息的分担 - 广播模式
每个消费者都要承担所有的消息
2.2 顺序消息
- Broker中可能有多个消息队列，假如生产者生产了4个消息，则不会进入同一个队列，而是轮询进入多个队列
- 消费者也会以多线程的方式，同时访问多个消息队列，同时执行
-
消费者消费消息的顺序要与生产者发送消息的顺序一致，如何保证？
- 保证生产者发送的一组消息进入同一个队列，消费者去并发去取队列中的消息即可
2.2.1 消息发送者
- 通过消息选择器：
三个参数：List<MessageQueue> mqs：可选的消息队列列表
Message msg：要发送的消息
Object arg：业务标识参数。将相同业务标识参数的放进同一个队列
2.2.2 消息消费者
2.3 延时消息
比如电商里，提交了一个订单就可以发送一个延时消息，1h后去检查这个订单的状态，如果还是未付款就取消订单释放库存
2.3.1 消息发送者设置
- 设置延迟等级
2.3.2 启动消息消费者
2.4 批量消息
批量发送消息能显著提高传递小消息的性能。限制是这些批量消息应该有相同topic，相同的waitStoreMsgOK，而且不能是延时消息。消息的总大小不能超过4MB，超过时，最好分割
2.5 过滤消息
- TAG：消费者可以根据tag选择自己想要的消息
- 一个消息只能有一个tag，对应复杂的场景可能不起作用。这种情况下可以使用SQL表达式筛选消息。
2.5.1 Tag过滤
2.5.2 SQL语法过滤
只有使用push模式的消费者才能使用SQL语句
- 消息生产者将消息设置键值对的属性。
- 消息消费者根据属性值使用SQL语法过滤
2.6 事务消息
2.6.1 流程分析
image.png
2.6.1.1 事务消息的发送与提交
- 发送消息（half消息）
- 服务端响应消息写入结果
- 根据发送结果执行执行本地事务。（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
- 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
2.6.1.2 事务消息的补偿流程
- 对没有Commit或Rollback的事务消息（pending状态的消息），从服务端发起一次"回查"
- Producer收到回查消息，检查回查消息对应的本地事务的状态
- 根据本地事务状态，重新Commit或者Rollback
其中。补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况
2.6.1.3 事务消息状态
事务消息共有三种状态：提交状态、回滚状态、中间状态
- 提交状态：提交事务，它允许消费者消费此消息
- 回滚状态：回滚事务，它代表该消息将被删除，不允许被消费
- 中间状态：中间状态，它代表需要检查消息队列来确定状态
