2.RocketMQ集群搭建与消息发送样例

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集群工作流程

1. 启动NameServer，NameServer起来后监听端口，等待Broker，Producer、Consumer连上来，相当于一个路由控制中心
2. Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息（IP+端口等）以及存储所有Topic信息。注册成功后，NamseSever集群中就有Topic跟Broker的映射
3. 收发消息前，先创建Topic，创建Topic时需指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
4. Producer发送消息，启动时先跟NameServer集群中的一台保持长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在Broker建立长连接从而向Broker发消息
5. Consumer与Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息

1.4mqadmin管理工具

1.5集群监控平台搭建

2.消息发送样例

• 消息生产者步骤分析

1. 创建消息生产者Producer，并制定生产者组名
2. 指定NameServer地址
3. 启动Producer
4. 创建消息对象，指定主题Topic、Tag和消息体
5. 发送消息
6. 关闭生产者Producer

• 消息消费者步骤分析

1. 创建消费者Consumer，制定消费者组名
2. 指定NameServer地址
3. 订阅主题Topic和Tag
4. 设置回调函数，处理消息
5. 启动消费者Consumer

2.1 基本样例

2.1.1 同步消息

2.1.2 异步消息

2.1.3 单向消息

2.1.4 消费消息

• 负载均衡模式
  默认。多个消费者共同承担消息的分担
• 广播模式
  每个消费者都要承担所有的消息

2.2 顺序消息

• Broker中可能有多个消息队列，假如生产者生产了4个消息，则不会进入同一个队列，而是轮询进入多个队列
• 消费者也会以多线程的方式，同时访问多个消息队列，同时执行
• 消费者消费消息的顺序要与生产者发送消息的顺序一致，如何保证？
  • 保证生产者发送的一组消息进入同一个队列，消费者去并发去取队列中的消息即可

2.2.1 消息发送者

• 通过消息选择器：

三个参数：List 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 事务消息的发送与提交

1. 发送消息（half消息）
2. 服务端响应消息写入结果
3. 根据发送结果执行执行本地事务。（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
4. 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）

2.6.1.2 事务消息的补偿流程

1. 对没有Commit或Rollback的事务消息（pending状态的消息），从服务端发起一次"回查"
2. Producer收到回查消息，检查回查消息对应的本地事务的状态
3. 根据本地事务状态，重新Commit或者Rollback
   其中。补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况

2.6.1.3 事务消息状态

事务消息共有三种状态：提交状态、回滚状态、中间状态

• 提交状态：提交事务，它允许消费者消费此消息
• 回滚状态：回滚事务，它代表该消息将被删除，不允许被消费
• 中间状态：中间状态，它代表需要检查消息队列来确定状态

2.6.2 发送事务消息