RocketMQ（用来保护消息数据的队列）

1. MQ介绍

1.1 MQ简介

• MQ(Message Queue)消息队列，是一种用来保存消息数据的队列
  • 队列
    • 数据结构的一种，特征为“先进先出”。
  • 消息
    • 可以理解为服务器间的业务请求
• 原始架构
  • 服务器中的A功能需要调用B、C模块才能完成
• 微服务架构
  • 服务器A向服务器B发送要执行的操作（视为消息）
  • 服务器A向服务器C发送要执行的操作（视为消息）

1.2 MQ作用

• 应用解耦
  • 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
    
  • 使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补偿处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。
    
• 流量削峰
  
  • 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。
    
  • 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验要好。处于经济考量目的：业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对流量高峰配置高性能的服务器显然不划算，这时可以使用消息队列对峰值流量削峰
• 数据分发
  
  • 通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可
    

1.3 MQ的优点和缺点

• 优点
  • 应用解耦
  • 流量削峰
  • 数据分发
• 缺点
  • 系统可用性降低
    • 系统引入的外部依赖越多，系统稳定性越差，一旦MQ宕机，就会对业务造成影响
  • 系统复杂度提高
    • MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用
  • 一致性问题
    • A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统处理成功，C系统处理成功，D系统处理失败，如何保证消息数据处理的一致性

1.4 各种MQ产品的比较

2. RocketMQ快速入门

2.1 各角色介绍

• Producer：消息的发送者；举例：发信者
• Consumer：消息接收者；举例：收信者
• Broker：暂存和传输消息；举例：邮局
• NameServer：管理Broker；举例：各个邮局的管理机构
• Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息
• Message Queue：相当于是Topic的分区；用于并行发送和接收消息
  
• RocketMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，在阿里内部，RocketMQ承接了例如“双11”等高并发场景的消息流转，能够处理万亿级别的消息。

2.2 下载安装

• 下载RocketMQ
  • https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zip
• 环境准备
  • Linux64位系统
  • JDK1.8（64位）
  • 源码安装需要安装Maven3.2.x
• 安装步骤
  • 解压安装包
  • 进入安装目录
    • bin：启动脚本，包括shell脚本和CMD脚本
    • conf：实例配置文件 ，包括broker配置文件、logback配置文件等
    • lib：依赖jar包，包括Netty、commons-lang、FastJSON等

2.3 启动RocketMQ

• 启动NameServer

  # 1.启动NameServer
  nohup sh bin/mqnamesrv &
  # 2.查看启动日志
  tail -f ~/logs/rocketmqlogs/namesrv.log
  

• 启动Broker

  # 1.启动Broker
  nohup sh bin/mqbroker -n localhost:9876 &
  # 2.查看启动日志
  tail -f ~/logs/rocketmqlogs/broker.log 
  

• 问题描述
  • RocketMQ默认的虚拟机内存较大，启动Broker如果因为内存不足失败，需要编辑如下两个配置文件，修改JVM内存大小

  # 编辑runbroker.sh和runserver.sh修改默认JVM大小
  vi runbroker.sh
  vi runserver.sh
  

  • 参考设置

  JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m  -XX:MaxMetaspaceSize=320m
  

2.4 测试RocketMQ

• 发送消息

# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.使用安装包的Demo发送消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

• 接收消息

# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

2.5 关闭RocketMQ

# 1.关闭NameServer
sh bin/mqshutdown namesrv
# 2.关闭Broker
sh bin/mqshutdown broker

3. 入门案例

3.1 准备工作

• 引入坐标：

  <dependency>
      <groupId>org.apache.rocketmqgroupId>
      <artifactId>rocketmq-clientartifactId>
      <version>4.5.2version>
  dependency>
  

• 消息发送者步骤分析
  • 创建消息生产者producer，并制定生产者组名
  • 指定Nameserver地址
  • 启动producer
  • 创建消息对象，指定主题Topic、Tag和消息体
  • 发送消息
  • 关闭生产者producer
• 消息消费者步骤分析
  • 创建消费者Consumer，制定消费者组名
  • 指定Nameserver地址
  • 订阅主题Topic和Tag
  • 设置回调函数，处理消息
  • 启动消费者consumer

3.2 代码实现

• 生产者代码实现

  public class Producer {
      public static void main(String[] args) throws Exception {
          //1.创建一个发送消息的对象Producer
          DefaultMQProducer producer = new DefaultMQProducer("group1");
          //2.设定发送的命名服务器地址
          producer.setNamesrvAddr("192.168.184.128:9876");
          //3.1启动发送的服务
          producer.start();
          //4.创建要发送的消息对象,指定topic，指定内容body
          Message msg = new Message("topic1","hello rocketmq".getBytes("UTF-8"));
          //3.2发送消息
          SendResult result = producer.send(msg);
          System.out.println("返回结果："+result);
          //5.关闭连接
          producer.shutdown();
      }
  }
  

• 消费者代码实现

  public class Consumer {
      public static void main(String[] args) throws Exception {
          //1.创建一个接收消息的对象Consumer
          DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
          //2.设定接收的命名服务器地址
          consumer.setNamesrvAddr("192.168.184.128:9876");
          //3.设置接收消息对应的topic,对应的sub标签为任意*
          consumer.subscribe("topic1","*");
          
          //------------多消费者模式（开始）---------------
          //设置当前消费者的消费模式（默认模式：负载均衡）
          //consumer.setMessageModel(MessageModel.CLUSTERING);
          //设置当前消费者的消费模式为广播模式：所有客户端接收的消息都是一样的
          //consumer.setMessageModel(MessageModel.BROADCASTING);
           //------------多消费者模式（结束）---------------
          
          //3.开启监听，用于接收消息
          consumer.registerMessageListener(new MessageListenerConcurrently() {
              public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> list, ConsumeConcurrentlyContext consumeConcurrentlyContext) {
                  //遍历消息
                  for(MessageExt msg : list){
                      System.out.println("消息："+new String(msg.getBody()));
                  }
                  return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
              }
          });
          //4.启动接收消息的服务
          consumer.start();
          System.out.println("接收消息服务已开启运行");
      }
  }
  

4. 消息类别

4.1 同步消息

• 特征： 即时性较强，重要的消息，且必须有回执的消息，例如短信，通知（转账成功）
  

4.2 异步消息

• 特征：即时性较弱，但需要有回执的消息， 例如订单中的某些信息
  
• 生产者代码实现

  public class Producer {
      public static void main(String[] args) throws Exception {
          DefaultMQProducer producer = new DefaultMQProducer("group1");
          producer.setNamesrvAddr("192.168.184.128:9876");
          producer.start();
          for (int i = 1; i <= 5; i++) {
              //异步消息发送
              Message msg = new Message("topic2",("异步消息：hello rocketmq "+i).getBytes("UTF-8"));
              producer.send(msg, new SendCallback() {
                  //表示成功返回结果
                  public void onSuccess(SendResult sendResult) {
                      System.out.println(sendResult);
                  }
                  //表示发送消息失败
                  public void onException(Throwable t) {
                      System.out.println(t);
                  }
              });
          }
          //添加一个休眠操作，确保异步消息返回后能够输出
          TimeUnit.SECONDS.sleep(10);
      }
  }
  

• 消费者代码实现
  • 同入门案例的消费者

4.3 单向消息

• 特征： 不需要有回执的消息，例如日志类消息
  
• 生产者代码实现

  public class Producer {
      public static void main(String[] args) throws Exception {
          DefaultMQProducer producer = new DefaultMQProducer("group1");
          producer.setNamesrvAddr("192.168.184.128:9876");
          producer.start();
          for (int i = 1; i <= 5; i++) {
              //单向消息
              Message msg = new Message("topic2",("单向消息：hello rocketmq "+i).getBytes("UTF-8"));
              producer.sendOneway(msg);
          }
  
          producer.shutdown();
      }
  }
  

• 消费者代码实现
  • 同入门案例的消费者

5. 延时消息

• 消息发送时并不直接发送到消息服务器，而是根据设定的等待时间到达，起到延时到达的缓冲作用 。
  • 目前支持的消息时间
    • 秒级： 1， 5， 10， 30
    • 分级： 1~10， 20， 30
    • 时级： 1， 2

  1s【0】 5s【1】 10s【2】 30s【3】 1m【4】 2m【5】 3m【6】 4m【7】 5m【8】 6m【9】 7m【10】 8m【11】 9m【12】 10m【13】 20m【14】 30m【15】 1h【16】 2h【17】

• 生产者代码实现：

  public class Producer {
      public static void main(String[] args) throws Exception {
          DefaultMQProducer producer = new DefaultMQProducer("group1");
          producer.setNamesrvAddr("192.168.184.128:9876");
          producer.start();
          for (int i = 1; i <= 5; i++) {
              Message msg = new Message("topic3",("非延时消息：hello rocketmq "+i).getBytes("UTF-8"));
              //设置当前消息的延时效果=========
              msg.setDelayTimeLevel(3);
              SendResult result = producer.send(msg);
              System.out.println("返回结果："+result);
          }
          producer.shutdown();
      }
  }
  

6. 批量消息

• 批量发送消息能显著提高传递小消息的性能。限制这些批消息有相同的topic，相同的waitStoreMsgOK，而且不能是延时消息。此外，这一批消息的总大小不应超过4MB。
• 代码实现：

public class Producer {
    public static void main(String[] args) throws Exception {
        DefaultMQProducer producer = new DefaultMQProducer("group1");
        producer.setNamesrvAddr("192.168.184.128:9876");
        producer.start();

        //创建一个集合保存多个消息
        List<Message> msgList = new ArrayList<Message>();

        Message msg1 = new Message("topic5",("批量消息：hello rocketmq "+1).getBytes("UTF-8"));
        Message msg2 = new Message("topic5",("批量消息：hello rocketmq "+2).getBytes("UTF-8"));
        Message msg3 = new Message("topic5",("批量消息：hello rocketmq "+3).getBytes("UTF-8"));

        msgList.add(msg1);
        msgList.add(msg2);
        msgList.add(msg3);

        //发送批量消息(每次发送的消息总量不得超过4M）
        //消息的总长度包含4个信息：topic,body,消息的属性,日志（20字节）
        SendResult send = producer.send(msgList);

        System.out.println(send);

        producer.shutdown();
    }
}

7. 消息过滤

7.1 分类过滤

• 对于一些简单的消息的过滤可以使用分类过滤
• 生产者代码：

//创建消息的时候除了制定topic，还可以指定tag
 Message msg = new Message("topic6","tag2",("消息过滤按照tag：hello rocketmq 2").getBytes("UTF-8"));

• 消费者代码：

//接收消息的时候，除了制定topic，还可以指定接收的tag,*代表任意tag
consumer.subscribe("topic6","tag1 || tag2");

7.2 sql过滤

• RocketMQ只定义了一些基本语法来支持这个特性。你也可以很容易地扩展它。
  • 数值比较，比如：>，>=，<，<=，BETWEEN，=；
  • 字符比较，比如：=，<>，IN；
  • IS NULL 或者 IS NOT NULL；
  • 逻辑符号 AND，OR，NOT；
• 常量支持类型为：
  • 数值，比如：123，3.1415；
  • 字符，比如：‘abc’，必须用单引号包裹起来；
  • NULL，特殊的常量
  • 布尔值，TRUE 或 FALSE
• 规则出处如下：
  
• 生产者代码
  • 发送消息时，你能通过putUserProperty来设置消息的属性

  Message msg = new Message("topic7",("消息过滤按照sql：hello rocketmq").getBytes("UTF-8"));
  //为消息添加属性
  msg.putUserProperty("age","20");
  

• 消费者代码
  • 用MessageSelector.bySql来使用sql筛选消息

  //使用消息选择器来过滤对应的属性，语法格式为类SQL语法
  //consumer.subscribe("TopicTest", MessageSelector.bySql("age between 10 and 30");
  consumer.subscribe("topic7", MessageSelector.bySql("age >= 18"));
  

• 注意
  • 需要开启对sql筛选，到 conf/broker.conf 配置文件添加如下配置
  • enablePropertyFilter=true
• 启动broker服务器
  • sh mqbroker -n localhost9876 -c ../conf/broker.conf

8. 顺序消息

8.1 介绍

• 概念
  • 消息有序指的是可以按照消息的发送顺序来消费(FIFO)。
• RocketMQ可以严格的保证消息有序，可以分为：
  • 分区有序
  • 全局有序。
• 顺序消费原理
  • 在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列)；而消费消息的时候从多个queue上拉取消息，这种情况发送和消费是不能保证顺序。
  • 但是如果控制发送的顺序消息只依次发送到同一个queue中，消费的时候只从这个queue上依次拉取，则就保证了顺序。
  • 当发送和消费参与的queue只有一个，则是全局有序。
  • 如果多个queue参与，则为分区有序，即相对每个queue，消息都是有序的。

8.2 生产者代码

public class Producer {
    public static void main(String[] args) throws Exception {
        DefaultMQProducer producer = new DefaultMQProducer("group1");
        producer.setNamesrvAddr("192.168.184.128:9876");
        producer.start();

        //创建要执行的业务队列
        List<Order> orderList = new ArrayList<Order>();

        Order order11 = new Order();
        order11.setId("a");
        order11.setMsg("主单-1");
        orderList.add(order11);

        Order order12 = new Order();
        order12.setId("a");
        order12.setMsg("子单-2");
        orderList.add(order12);

        Order order13 = new Order();
        order13.setId("a");
        order13.setMsg("支付-3");
        orderList.add(order13);

        Order order14 = new Order();
        order14.setId("a");
        order14.setMsg("推送-4");
        orderList.add(order14);

        Order order21 = new Order();
        order21.setId("b");
        order21.setMsg("主单-1");
        orderList.add(order21);

        Order order22 = new Order();
        order22.setId("b");
        order22.setMsg("子单-2");
        orderList.add(order22);

        Order order31 = new Order();
        order31.setId("c");
        order31.setMsg("主单-1");
        orderList.add(order31);

        Order order32 = new Order();
        order32.setId("c");
        order32.setMsg("子单-2");
        orderList.add(order32);

        Order order33 = new Order();
        order33.setId("c");
        order33.setMsg("支付-3");
        orderList.add(order33);

        //设置消息进入到指定的消息队列中
        for(final Order order : orderList){
            Message msg = new Message("orderTopic",order.toString().getBytes());
            //发送时要指定对应的消息队列选择器
            SendResult result = producer.send(msg, new MessageQueueSelector() {
                //设置当前消息发送时使用哪一个消息队列
                public MessageQueue select(List<MessageQueue> list, Message message, Object o) {
                    //根据发送的信息不同，选择不同的消息队列
                    //根据id来选择一个消息队列的对象，并返回->id得到int值
                    int mqIndex = order.getId().hashCode() % list.size();
                    return list.get(mqIndex);
                }
            }, null);

            System.out.println(result);
        }
        producer.shutdown();
    }
}

8.3 消费者代码

public class Consumer {
    public static void main(String[] args) throws Exception {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
        consumer.setNamesrvAddr("192.168.184.128:9876");
        consumer.subscribe("orderTopic","*");

        //使用单线程的模式从消息队列中取数据，一个线程绑定一个消息队列  MessageListenerOrderly
        consumer.registerMessageListener(new MessageListenerOrderly() {
            //使用MessageListenerOrderly接口后，对消息队列的处理由一个消息队列多个线程服务，转化为一个消息队列一个线程服务
            public ConsumeOrderlyStatus consumeMessage(List<MessageExt> list, ConsumeOrderlyContext consumeOrderlyContext) {
                for(MessageExt msg : list){
                    System.out.println(Thread.currentThread().getName()+"  消息："+new String(msg.getBody()));
                }
                return ConsumeOrderlyStatus.SUCCESS;
            }
        });

        consumer.start();
        System.out.println("接收消息服务已开启运行");
    }
}

9. 事务消息

9.1 执行流程

• 上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。
• 事务消息发送及提交
  • 发送消息（half消息）。
  • 服务端响应消息写入结果。
  • 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。
  • 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
• 事务补偿
  • 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
  • Producer收到回查消息，检查回查消息对应的本地事务的状态
  • 根据本地事务状态，重新Commit或者Rollback
  • 其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。
• 事务消息状态
  • TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息。
  • TransactionStatus.RollbackTransaction: 回滚事务，它代表该消息将被删除，不允许被消费。
  • TransactionStatus.Unknown: 中间状态，它代表需要检查消息队列来确定状态。

9.2 创建事务性生产者

• 使用 TransactionMQProducer类创建生产者，并指定唯一的 ProducerGroup，就可以设置自定义线程池来处理这些检查请求。执行本地事务后、需要根据执行结果对消息队列进行回复。

public class Producer {
    public static void main(String[] args) throws Exception {
        //事务消息使用的生产者是TransactionMQProducer
        TransactionMQProducer producer = new TransactionMQProducer("group1");
        producer.setNamesrvAddr("192.168.184.128:9876");
        //添加本地事务对应的监听
        producer.setTransactionListener(new TransactionListener() {
            //正常事务过程
            public LocalTransactionState executeLocalTransaction(Message message, Object o) {
                //中间状态
                return LocalTransactionState.UNKNOW;
            }
            //事务补偿过程
            public LocalTransactionState checkLocalTransaction(MessageExt messageExt) {
                System.out.println("事务补偿过程执行");
                return LocalTransactionState.COMMIT_MESSAGE;
            }
        });
        producer.start();

        Message msg = new Message("topic11",("事务消息：hello rocketmq ").getBytes("UTF-8"));
        SendResult result = producer.sendMessageInTransaction(msg,null);
        System.out.println("返回结果："+result);
        //事务补偿过程必须保障服务器在运行过程中，否则将无法进行正常的事务补偿
//      producer.shutdown();
    }

9.3 创建事务性消费者

• 消费者和之前创建的方式一样。

public class Consumer {
    public static void main(String[] args) throws Exception {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
        consumer.setNamesrvAddr("192.168.184.128:9876");
        consumer.subscribe("topic11","*");

        consumer.registerMessageListener(new MessageListenerConcurrently() {
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> list, ConsumeConcurrentlyContext consumeConcurrentlyContext) {
                for(MessageExt msg : list){
                    System.out.println("消息："+new String(msg.getBody()));
                }
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });
        consumer.start();
        System.out.println("接收消息服务已开启运行");
    }
}

10. 集群介绍

10.1 集群特点

• NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
• Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
• Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
• Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

10.2 集群模式

• 单Master模式
  • 这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。
• 多Master模式
  • 一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：
    • 优点：配置简单，单个Master宕机或重启维护对应用无影响，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
    • 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
• 多Master多Slave模式（异步）
  • 每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
    • 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
    • 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
• 多Master多Slave模式（同步）
  • 每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：
    • 优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
    • 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

11. 双主双从集群搭建

11.1 总体架构

• 消息高可用采用2m-2s（同步双写）方式：
  

11.2 集群工作流程

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

11.3 服务器环境

序号	IP	角色	架构模式
1	192.168.25.135	nameserver、brokerserver	Master1、Slave2
2	192.168.25.138	nameserver、brokerserver	Master2、Slave1

11.4 Host添加信息

vim /etc/hosts

• 配置如下:

# nameserver
192.168.25.135 rocketmq-nameserver1
192.168.25.138 rocketmq-nameserver2
# broker
192.168.25.135 rocketmq-master1
192.168.25.135 rocketmq-slave2
192.168.25.138 rocketmq-master2
192.168.25.138 rocketmq-slave1

• 配置完成后, 重启网卡

systemctl restart network

11.5 防火墙配置

• 宿主机需要远程访问虚拟机的rocketmq服务和web服务，需要开放相关的端口号，简单粗暴的方式是直接关闭防火墙

# 关闭防火墙
systemctl stop firewalld.service 
# 查看防火墙的状态
firewall-cmd --state 
# 禁止firewall开机启动
systemctl disable firewalld.service

• 或者为了安全，只开放特定的端口号，RocketMQ默认使用3个端口：9876 、10911 、11011 。如果防火墙没有关闭的话，那么防火墙就必须开放这些端口：
  • nameserver 默认使用 9876 端口
  • master 默认使用 10911 端口
  • slave 默认使用11011 端口
• 执行以下命令：

# 开放name server默认端口
firewall-cmd --remove-port=9876/tcp --permanent
# 开放master默认端口
firewall-cmd --remove-port=10911/tcp --permanent
# 开放slave默认端口 (当前集群模式可不开启)
firewall-cmd --remove-port=11011/tcp --permanent 
# 重启防火墙
firewall-cmd --reload

11.6 环境变量配置

vim /etc/profile

• 在profile文件的末尾加入如下命令

#set rocketmq
ROCKETMQ_HOME=/usr/local/src/rocketmq
PATH=$PATH:$ROCKETMQ_HOME/bin
export ROCKETMQ_HOME PATH

• 输入:wq! 保存并退出， 并使得配置立刻生效：

source /etc/profile

11.7 创建消息存储路径

mkdir /usr/local/src/rocketmq/store
mkdir /usr/local/src/rocketmq/store/commitlog
mkdir /usr/local/src/rocketmq/store/consumequeue
mkdir /usr/local/src/rocketmq/store/index

11.8 broker配置文件

11.8.1 master1

• 服务器：192.168.25.135

vi /usr/local/src/rocketmq/conf/2m-2s-sync/broker-a.properties

• 修改配置如下：

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/src/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/src/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/src/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/src/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/src/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/src/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

11.8.2 slave2

• 服务器：192.168.25.135

vi /usr/local/src/rocketmq/conf/2m-2s-sync/broker-b-s.properties

• 修改配置如下：

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-b
#0 表示 Master，>0 表示 Slave
brokerId=1
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=11011
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/src/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/src/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/src/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/src/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/src/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/src/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SLAVE
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

11.8.3 master2

• 服务器：192.168.25.138

vim /usr/local/src/rocketmq/conf/2m-2s-sync/broker-b.properties

• 修改配置如下：

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-b
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/src/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/src/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/src/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/src/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/src/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/src/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

11.8.4 slave1

• 服务器：192.168.25.138

vim /usr/local/src/rocketmq/conf/2m-2s-sync/broker-a-s.properties

• 修改配置如下：

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=1
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=11011
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/src/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/src/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/src/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/src/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/src/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/src/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SLAVE
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

11.9 修改启动脚本文件

11.9.1 runbroker.sh

vim /usr/local/src/rocketmq/bin/runbroker.sh

• 需要根据内存大小进行适当的对JVM参数进行调整：

# 开发环境配置 JVM Configuration
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"

11.9.2 runserver.sh

vim /usr/local/src/rocketmq/bin/runserver.sh

JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"

11.10 服务启动

11.10.1启动NameServe集群

• 分别在192.168.25.135和192.168.25.138启动NameServer

  cd /usr/local/src/rocketmq/bin
  nohup sh mqnamesrv &
  

11.10.2 启动Broker集群

• 在192.168.25.135上启动master1和slave2
  • master1：

  cd /usr/local/src/rocketmq/bin
  nohup sh mqbroker  -c /usr/local/src/rocketmq/conf/2m-2s-sync/broker-a.properties &
  

  • slave2：

  cd /usr/local/src/rocketmq/bin
  nohup sh mqbroker nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
  

• 在192.168.25.138上启动master2和slave2
  • master2

  cd /usr/local/src/rocketmq/bin
  nohup sh mqbroker -c /usr/local/src/rocketmq/conf/2m-2s-sync/broker-b.properties &
  

  • slave1

  cd /usr/local/src/rocketmq/bin
  nohup sh mqbroker -c /usr/local/src/rocketmq/conf/2m-2s-sync/broker-a-s.properties &
  

生产者代码和消费者代码需要指定多个nameserver
producer.setNamesrvAddr(“192.168.25.148:9876;192.168.25.150:9876”);
consumer.setNamesrvAddr(“192.168.25.148:9876;192.168.25.150:9876”);

11.11 查看进程状态

• 启动后通过JPS查看启动进程
  

11.12 查看日志

# 查看nameServer日志
tail -500f ~/logs/rocketmqlogs/namesrv.log
# 查看broker日志
tail -500f ~/logs/rocketmqlogs/broker.log

12. 集群监控平台

2.1 概述

• RocketMQ有一个对其扩展的开源项目 incubator-rocketmq-externals，这个项目中有一个子模块叫rocketmq-console，这个便是管理控制台项目了，先将incubator-rocketmq-externals拉到本地，因为我们需要自己对 rocketmq-console进行编译打包运行。
  

2.2 下载并编译打包

git clone https://github.com/apache/rocketmq-externals
cd rocketmq-console
mvn clean package -Dmaven.test.skip=true

• 注意：打包前在rocketmq-console中配置namesrv集群地址：

rocketmq.config.namesrvAddr=192.168.25.135:9876;192.168.25.138:9876

• 启动rocketmq-console：

java -jar rocketmq-console-ng-1.0.0.jar

• 启动成功后，我们就可以通过浏览器访问http://localhost:8080进入控制台界面了，如下图：
  
• 集群状态：
  

13. 高级功能

13.1 消息存储

13.1.1 介绍

• 分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。
  
  • 消息生成者发送消息
  • MQ收到消息，将消息进行持久化，在存储中新增一条记录
  • 返回ACK给生产者
  • MQ push 消息给对应的消费者，然后等待消费者返回ACK
  • 如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤
  • MQ删除消息

13.1.2 存储介质

• 关系型数据库DB
  • Apache下开源的另外一款MQ—ActiveMQ（默认采用的KahaDB做消息存储）可选用JDBC的方式来做消息持久化，通过简单的xml配置信息即可实现JDBC消息存储。由于，普通关系型数据库（如Mysql）在单表数据量达到千万级别的情况下，其IO读写性能往往会出现瓶颈。在可靠性方面，该种方案非常依赖DB，如果一旦DB出现故障，则MQ的消息就无法落盘存储会导致线上故障
• 文件系统
  • 目前业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ）均采用的是消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。消息刷盘为消息存储提供了一种高效率、高可靠性和高性能的数据持久化方式。除非部署MQ机器本身或是本地磁盘挂了，否则一般是不会出现无法持久化的故障问题。
• 性能对比
  • 文件系统>关系型数据库DB

13.1.3 消息存储

• 磁盘如果使用得当，磁盘的速度完全可以匹配上网络 的数据传输速度。目前的高性能磁盘，顺序写速度可以达到600MB/s， 超过了一般网卡的传输速度。但是磁盘随机写的速度只有大概100KB/s，和顺序写的性能相差6000倍！因为有如此巨大的速度差别，好的消息队列系统会比普通的消息队列系统速度快多个数量级。RocketMQ的消息用顺序写,保证了消息存储的速度。

13.1.4 消息发送

• Linux操作系统分为【用户态】和【内核态】，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制。
• 一台服务器 把本机磁盘文件的内容发送到客户端，一般分为两个步骤：
  • read；读取本地文件内容；
  • write；将读取的内容通过网络发送出去。
• 这两个看似简单的操作，实际进行了4 次数据复制，分别是：
  • 从磁盘复制数据到内核态内存；
  • 从内核态内存复 制到用户态内存；
  • 然后从用户态 内存复制到网络驱动的内核态内存；
  • 最后是从网络驱动的内核态内存复 制到网卡中进行传输。
    
• 通过使用mmap的方式，可以省去向用户态的内存复制，提高速度。这种机制在Java中是通过MappedByteBuffer实现的
• RocketMQ充分利用了上述特性，也就是所谓的“零拷贝”技术，提高消息存盘和网络发送的速度。

这里需要注意的是，采用MappedByteBuffer这种内存映射的方式有几个限制，其中之一是一次只能映射1.5~2G 的文件至用户态的虚拟内存，这也是为何RocketMQ默认设置单个CommitLog日志数据文件为1G的原因了

13.1.5 消息存储结构

• RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成 的，消息真正的物理存储文件是CommitLog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每 个Topic下的每个Message Queue都有一个对应的ConsumeQueue文件。
  
• CommitLog：存储消息的元数据
• ConsumerQueue：存储消息在CommitLog的索引
• IndexFile：为了消息查询提供了一种通过key或时间区间来查询消息的方法，这种通过IndexFile来查找消息的方法不影响发送与消费消息的主流程

13.1.6 刷盘机制

• RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复， 又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时 候，有两种写磁盘方式，分布式同步刷盘和异步刷盘。
  
• 同步刷盘
  • 在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘， 然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写 成功的状态。
• 异步刷盘
  • 在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。
• 配置
  • 无论同步刷盘还是异步刷盘，都是通过Broker配置文件里的flushDiskType 参数设置的，这个参数被配置成SYNC_FLUSH、ASYNC_FLUSH中的 一个。

13.2 高可用性机制

• RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。
• Master和Slave的区别：
  • 在Broker的配置文件中，参数 brokerId的值为0表明这个Broker是Master，大于0表明这个Broker是 Slave，同时brokerRole参数也会说明这个Broker是Master还是Slave。
  • Master角色的Broker支持读和写，Slave角色的Broker仅支持读，也就是 Producer只能和Master角色的Broker连接写入消息；Consumer可以连接 Master角色的Broker，也可以连接Slave角色的Broker来读取消息。
• 消息消费高可用
  • 在Consumer的配置文件中，并不需要设置是从Master读还是从Slave 读，当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。有了自动切换Consumer这种机制，当一个Master角色的机器出现故障后，Consumer仍然可以从Slave读取消息，不影响Consumer程序。这就达到了消费端的高可用性。
• 消息发送高可用
  • 在创建Topic的时候，把Topic的多个Message Queue创建在多个Broker组上（相同Broker名称，不同 brokerId的机器组成一个Broker组），这样当一个Broker组的Master不可 用后，其他组的Master仍然可用，Producer仍然可以发送消息。 RocketMQ目前还不支持把Slave自动转成Master，如果机器资源不足， 需要把Slave转成Master，则要手动停止Slave角色的Broker，更改配置文 件，用新的配置文件启动Broker。
    
• 消息主从复制
  • 如果一个Broker组有Master和Slave，消息需要从Master复制到Slave 上，有同步和异步两种复制方式。
  • 同步复制
    • 同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态；
    • 在同步复制方式下，如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入 延迟，降低系统吞吐量。
  • 异步复制
    • 异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。
    • 在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写 入Slave，有可能会丢失；
  • 配置
    • 同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、 SYNC_MASTER、SLAVE三个值中的一个。
  • 总结
    • 实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式， 尤其是SYNC_FLUSH方式，由于频繁地触发磁盘写动作，会明显降低 性能。通常情况下，应该把Master和Save配置成ASYNC_FLUSH的刷盘 方式，主从之间配置成SYNC_MASTER的复制方式，这样即使有一台 机器出故障，仍然能保证数据不丢，是个不错的选择。

13.3 负载均衡

13.3.1 Producer负载均衡

• Producer端，每个实例在发消息的时候，默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。而由于queue可以散落在不同的broker，所以消息就发送到不同的broker下，如下图：
  
• 图中箭头线条上的标号代表顺序，发布方会把第一条消息发送至 Queue 0，然后第二条消息发送至 Queue 1，以此类推。

13.3.2 Consumer负载均衡

• 集群模式
  • 在集群消费模式下，每条消息只需要投递到订阅这个topic的Consumer Group下的一个实例即可。RocketMQ采用主动拉取的方式拉取并消费消息，在拉取的时候需要明确指定拉取哪一条message queue。而每当实例的数量有变更，都会触发一次所有实例的负载均衡，这时候会按照queue的数量和实例的数量平均分配queue给每个实例。
  • 默认的分配算法是AllocateMessageQueueAveragely，如下图：
    
  • 还有另外一种平均的算法是AllocateMessageQueueAveragelyByCircle，也是平均分摊每一条queue，只是以环状轮流分queue的形式，如下图：
    
  • 需要注意的是，集群模式下，queue都是只允许分配只一个实例，这是由于如果多个实例同时消费一个queue的消息，由于拉取哪些消息是consumer主动控制的，那样会导致同一个消息在不同的实例下被消费多次，所以算法上都是一个queue只分给一个consumer实例，一个consumer实例可以允许同时分到不同的queue。
  • 通过增加consumer实例去分摊queue的消费，可以起到水平扩展的消费能力的作用。而有实例下线的时候，会重新触发负载均衡，这时候原来分配到的queue将分配到其他实例上继续消费。
  • 但是如果consumer实例的数量比message queue的总数量还多的话，多出来的consumer实例将无法分到queue，也就无法消费到消息，也就无法起到分摊负载的作用了。所以需要控制让queue的总数量大于等于consumer的数量。
• 广播模式
  • 由于广播模式下要求一条消息需要投递到一个消费组下面所有的消费者实例，所以也就没有消息被分摊消费的说法。
  • 在实现上，其中一个不同就是在consumer分配queue的时候，所有consumer都分到所有的queue。
    

13.4 消息重试

13.4.1 顺序消息的重试

• 对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。因此，在使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。

13.4.2 无序消息的重试

• 对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。
• 无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
• 重试次数
  • 消息队列 RocketMQ 默认允许每条消息最多重试 16 次，每次重试的间隔时间如下：

    第几次重试	与上次重试的间隔时间	第几次重试	与上次重试的间隔时间
    1	10 秒	9	7 分钟
    2	30 秒	10	8 分钟
    3	1 分钟	11	9 分钟
    4	2 分钟	12	10 分钟
    5	3 分钟	13	20 分钟
    6	4 分钟	14	30 分钟
    7	5 分钟	15	1 小时
    8	6 分钟	16	2 小时

  • 如果消息重试 16 次后仍然失败，消息将不再投递。如果严格按照上述重试时间间隔计算，某条消息在一直消费失败的前提下，将会在接下来的 4 小时 46 分钟之内进行 16 次重试，超过这个时间范围消息将不再重试投递。

  注意：一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。

13.4.3 配置方式

• 消费失败后，重试配置方式
• 集群消费方式下，消息消费失败后期望消息重试，需要在消息监听器接口的实现中明确进行配置（三种方式任选一种）：
  • 返回 Action.ReconsumeLater （推荐）
  • 返回 Null
  • 抛出异常

  public class MessageListenerImpl implements MessageListener {
      @Override
      public Action consume(Message message, ConsumeContext context) {
          //处理消息
          doConsumeMessage(message);
          //方式1：返回 Action.ReconsumeLater，消息将重试
          return Action.ReconsumeLater;
          //方式2：返回 null，消息将重试
          return null;
          //方式3：直接抛出异常， 消息将重试
          throw new RuntimeException("Consumer Message exceotion");
      }
  }
  

• 消费失败后，不重试配置方式
• 集群消费方式下，消息失败后期望消息不重试，需要捕获消费逻辑中可能抛出的异常，最终返回 Action.CommitMessage，此后这条消息将不会再重试。

  public class MessageListenerImpl implements MessageListener {
      @Override
      public Action consume(Message message, ConsumeContext context) {
          try {
              doConsumeMessage(message);
          } catch (Throwable e) {
              //捕获消费逻辑中的所有异常，并返回 Action.CommitMessage;
              return Action.CommitMessage;
          }
          //消息处理正常，直接返回 Action.CommitMessage;
          return Action.CommitMessage;
      }
  }
  

• 自定义消息最大重试次数
• 消息队列 RocketMQ 允许 Consumer 启动的时候设置最大重试次数，重试时间间隔将按照如下策略：
  • 最大重试次数小于等于 16 次，则重试时间间隔同上表描述。
  • 最大重试次数大于 16 次，超过 16 次的重试时间间隔均为每次 2 小时。

  Properties properties = new Properties();
  //配置对应 Group ID 的最大消息重试次数为 20 次
  properties.put(PropertyKeyConst.MaxReconsumeTimes,"20");
  Consumer consumer =ONSFactory.createConsumer(properties);
  

  注意

  • 消息最大重试次数的设置对相同 Group ID 下的所有 Consumer 实例有效。
  • 如果只对相同 Group ID 下两个 Consumer 实例中的其中一个设置了 MaxReconsumeTimes，那么该配置对两个 Consumer 实例均生效。
  • 配置采用覆盖的方式生效，即最后启动的 Consumer 实例会覆盖之前的启动实例的配置

• 获取消息重试次数
• 消费者收到消息后，可按照如下方式获取消息的重试次数：

  public class MessageListenerImpl implements MessageListener {
      @Override
      public Action consume(Message message, ConsumeContext context) {
          //获取消息的重试次数
          System.out.println(message.getReconsumeTimes());
          return Action.CommitMessage;
      }
  }
  

13.5 死信队列

13.5.1 介绍

• 当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。
• 在消息队列 RocketMQ 中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。

13.5.2 死信特性

• 死信消息具有以下特性
  • 不会再被消费者正常消费。
  • 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，请在死信消息产生后的 3 天内及时处理。
• 死信队列具有以下特性：
  • 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。
  • 如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。
  • 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

13.5.3 查看死信信息

• 在控制台查询出现死信队列的主题信息
  
• 在消息界面根据主题查询死信消息
  
• 选择重新发送消息
  • 一条消息进入死信队列，意味着某些因素导致消费者无法正常消费该消息，因此，通常需要您对其进行特殊处理。排查可疑因素并解决问题后，可以在消息队列 RocketMQ 控制台重新发送该消息，让消费者重新消费一次。

13.6 消费幂等

• 消息队列 RocketMQ 消费者在接收到消息以后，有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。
• 在互联网应用中，尤其在网络不稳定的情况下，消息队列 RocketMQ 的消息有可能会出现重复，这个重复简单可以概括为以下情况：
  • 发送时消息重复
    • 当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
  • 投递时消息重复
    • 消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
  • 负载均衡时消息重复（包括但不限于网络抖动、Broker 重启以及订阅方应用重启）
    • 当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息。
• 处理方式
  • 因为 Message ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置：

  Message message = new Message();
  message.setKey("ORDERID_100");
  SendResult sendResult = producer.send(message);
  

  • 订阅方收到消息时可以根据消息的 Key 进行幂等处理：

  consumer.subscribe("ons_test", "*", new MessageListener() {
      public Action consume(Message message, ConsumeContext context) {
          String key = message.getKey()
          // 根据业务唯一标识的 key 做幂等处理
      }
  });