Docker 部署 RocketMQ 5.0

Github

• https://github.com/apache/rocketmq

官网

• https://rocketmq.apache.org/zh/

文档

• https://rocketmq.apache.org/zh/docs/

简介

RocketMQ 5.0 引入了全新的弹性无状态代理模式，将当前的Broker职责进行拆分，对于客户端协议适配、权限管理、消费管理等计算逻辑进行抽离，独立无状态的代理角色提供服务，Broker则继续专注于存储能力的持续优化。这套模式可以更好地实现在云环境的资源弹性调度。 值得注意的是RocketMQ 5.0的全新模式是和4.0的极简架构模式相容相通的，5.0的代理架构完全可以以Local模式运行，实现与4.0架构完全一致的效果。开发者可以根据自身的业务场景自由选择架构部署。

• Namesrv (Name Server)：

  • Namesrv 是 Name Server 的简写，主要负责管理 Broker 的元数据信息和路由信息。
  • Namesrv 维护着 Topic、Producer 和 Consumer 的路由信息，以及 Broker 的地址信息。
  • Producer 和 Consumer 在启动时会向 Namesrv 注册自己，并定期从 Namesrv 获取最新的路由信息，以便能够正确地发送和接收消息。

• Broker：

  • Broker 是 RocketMQ 中存储消息的节点，负责接收来自 Producer 的消息，并将其存储到相应的 Topic 中。
  • 同时，Broker 也负责从存储中检索消息，并将其发送给 Consumer。
  • 一个 Broker 可以管理多个 Topic，每个 Topic 可以有多个队列，以实现负载均衡和高可用性。
  • Broker 还负责消息的复制和同步，以确保消息的可靠传输和高可用性。

• Proxy：

  • Proxy 是 RocketMQ 中的代理组件，主要负责为 Producer 和 Consumer 提供代理服务。
  • Proxy 位于 Producer 和 Consumer 之间，负责代理它们的请求，并将其转发给相应的 Broker 或 Namesrv。
  • Proxy 可以实现负载均衡、故障转移和流量控制等功能，以提高系统的可用性和性能。
  • Proxy 是一个无状态的中间件组件，它不保存与客户端连接相关的状态信息，可以轻松地实现水平扩展和负载均衡。

Docker 镜像

• https://hub.docker.com/r/apache/rocketmq

docker pull apache/rocketmq:5.2.0

Docker 部署

• 创建目录

├── rocketmq
│   ├── broker
│   │   ├── store
│   │   ├── logs
│   ├── namesrv
│   │   ├── logs
│   ├── proxy
│   │   ├── logs

mkdir rocketmq && cd rocketmq
mkdir broker namesrv proxy
cd namesrv && mkdir logs
cd broker && mkdir store logs
cd proxy && mkdir logs

• docker-compose.yml

services:
  rocketmq-dashboard:
    image: apacherocketmq/rocketmq-dashboard:latest
    container_name: rocketmq-dashboard
    ports:
      - 8000:8080
    environment:
      - JAVA_OPTS=-Drocketmq.namesrv.addr=rmqnamesrv:9876
    networks:
      - rocketmq
  namesrv:
    image: apache/rocketmq:5.2.0
    container_name: rmqnamesrv
    ports:
      - 9876:9876
    volumes:
      - ./rocketmq/namesrv/logs:/home/rocketmq/logs/rocketmqlogs
    networks:
      - rocketmq
    command: sh mqnamesrv
  broker:
    image: apache/rocketmq:5.2.0
    container_name: rmqbroker
    ports:
      - 10909:10909
      - 10911:10911
      - 10912:10912
    environment:
      - NAMESRV_ADDR=rmqnamesrv:9876
    volumes:
      - ./rocketmq/broker/store:/home/rocketmq/store
      - ./rocketmq/broker/logs:/home/rocketmq/logs/rocketmqlogs
    depends_on:
      - namesrv
    networks:
      - rocketmq
    command: sh mqbroker
  proxy:
    image: apache/rocketmq:5.2.0
    container_name: rmqproxy
    networks:
      - rocketmq
    depends_on:
      - broker
      - namesrv
    ports:
      - 8080:8080
      - 8081:8081
    restart: on-failure
    environment:
      - NAMESRV_ADDR=rmqnamesrv:9876
    volumes:
      - ./rocketmq/proxy/logs:/home/rocketmq/logs/rocketmqlogs
    command: sh mqproxy
networks:
  rocketmq:
    driver: bridge

• 部署 namesrv broker proxy

docker-compose up -d proxy

• 容器启动日志

# 验证 Namesrv 是否启动成功
docker exec -it rmqnamesrv bash -c "tail -n 10 /home/rocketmq/logs/rocketmqlogs/namesrv.log"
# 验证 Broker 是否启动成功
docker exec -it rmqbroker bash -c "tail -n 10 /home/rocketmq/logs/rocketmqlogs/broker.log"
# 验证 Proxy 是否启动成功
docker exec -it rmqproxy bash -c "tail -n 10 /home/rocketmq/logs/rocketmqlogs/proxy.log"

• 部署 dashboard

docker-compose up -d rocketmq-dashboard

• http://localhost:8000/#/

消息类型

普通消息

• 同步发送： 同步发送是指消息发送方发送消息后会等待消息服务器（Broker）的响应，直到收到确认或者超时才返回。

  • 对消息可靠性要求高的场景，例如订单支付、资金交易等。
  • 对发送消息的吞吐量要求不是特别高的场景，因为同步发送会阻塞等待服务器响应，可能会影响发送方的性能。

• 异步发送： 异步发送是指消息发送方发送消息后不等待服务器响应，而是立即返回，通过回调函数处理服务器响应。

  • 对发送消息的吞吐量要求较高的场景，因为异步发送不会阻塞发送方，可以提高发送方的性能。
  • 对消息可靠性要求一般的场景，例如日志记录、统计数据等，可以通过重试机制来保证消息的可靠性。

顺序消息

• 顺序消息是指消息消费的顺序与消息发送的顺序一致。
• RocketMQ 通过消息队列和消息队列中的消息分区来实现顺序消息。在同一个消息队列中的消息将按照发送顺序进行消费，不同消息队列之间的消息则可能并发消费。
• 应用场景：
  • 需要保证消息处理的顺序性，例如订单处理、日志记录等。
  • 需要避免消息处理的并发冲突，例如库存同步、账户余额更新等。

定时/延时消息

• 定时/延时消息是指消息发送后会在一定的时间延迟后才被消费者接收。
• RocketMQ 提供了消息延迟发送的功能，可以在发送消息时设置消息的延迟时间。
• 应用场景：
  • 需要在未来的某个特定时间点触发某些操作，例如定时任务调度、消息提醒等。
  • 需要实现消息的重试机制，可以通过延迟发送实现消息重试的逻辑。

事务消息

• 事务消息是指发送方发送消息后，消息并不立即被消费者接收，而是处于预提交状态，需要发送方确认后消息才会被真正发送到消费者。
• RocketMQ 提供了事务消息的支持，通过发送方的确认和回查机制来保证消息的可靠传递。
• 应用场景：
  • 需要保证消息发送的原子性操作，例如分布式事务、多个系统间的数据同步等。
  • 需要在消息发送和消息确认之间进行一些业务逻辑处理，例如本地事务的提交、回滚等。