docker-compose 部署rocketmq cluster

docker-compose 部署rocketmq cluster

制作rocketmq镜像

1、下载

直接克隆官方镜像制作文件

# git clone https://github.com/apache/rocketmq-docker.git

[root@localhost rocketmq-docker-master]# ls
CONTRIBUTING.md image-build LICENSE NOTICE product README.md stages stage.sh templates

[root@localhost rocketmq-docker-master]# cd image-build/
[root@localhost image-build]# ls
build-image-dashboard.sh build-image.sh Dockerfile-alpine Dockerfile-centos Dockerfile-centos-dashboard scripts update.sh

2、创建RocketMQ镜像

构建命令: sh build-image.sh RMQ-VERSION BASE-IMAGE
可选RMQ-VERSION

例如: sh build-image.sh 4.7.0 centos (or alpine)

构建时间比较长

//构建完成

Successfully built 128108c2e50d

Successfully tagged apacherocketmq/rocketmq:4.7.1-alpine

[root@localhost image-build]# docker images |grep mq
apacherocketmq/rocketmq 4.7.0 28ce832d84bf 59 minutes ago 533MB

3、生成配置

[root@localhost rocketmq-docker-master]# sh stage.sh 4.7.0
Stage version = 4.7.0
mkdir /root/rocketmq-docker-master/stages/4.7.0
staged templates into folder /root/rocketmq-docker-master/stages/4.7.0

[root@localhost templates]# ls
data docker-compose kubernetes play-consumer.sh play-docker-compose.sh play-docker-dledger.sh play-docker.sh play-docker-tls.sh play-kubernetes.sh play-producer.sh ssl

4、部署方式

  1、单机

    ./play-docker.sh alpine

  2、docker-composer

    ./play-docker-compose.sh

  3、kubernetes集群

     ./play-kubernetes.sh

  4、Cluster of Dledger storage(RocketMQ需要4.4.0版本以上)

    ./play-docker-dledger.sh

  5、TLS

    ./play-docker-tls.sh

    ./play-producer.sh

    ./play-consumer.sh

  我这里选择的是单机部署,可以看到生成了两个容器

[root@localhost templates]# docker ps |grep mq
9a0a6ab594b7 apacherocketmq/rocketmq:4.7.0 "sh mqbroker" 56 minutes ago Up 56 minutes 0.0.0.0:10909->10909/tcp, :::10909->10909/tcp, 9876/tcp, 0.0.0.0:10911-10912->10911-10912/tcp, :::1091110912->10911-10912/tcp rmqbroker
d8a4db8335de apacherocketmq/rocketmq:4.7.0 "sh mqnamesrv" 56 minutes ago Up 56 minutes 10909/tcp, 0.0.0.0:9876->9876/tcp, :::9876->9876/tcp, 10911-10912/tcp rmqnamesrv

  验证RocketMQ启动成功

1、使用命令 docker ps|grep rmqbroker找到RocketMQ broker的容器id

2、使用命令 docker exec -it 9a0a6ab594b7 ./mqadmin clusterList -n 172.17.0.8:9876 验证RocketMQ broker工作正常

[root@localhost elasticsearch]# docker exec -it 9a0a6ab594b7 ./mqadmin clusterList -n 192.168.1.204:9876
RocketMQLog:WARN No appenders could be found for logger (io.netty.util.internal.PlatformDependent0).
RocketMQLog:WARN Please initialize the logger system properly.

  如需升级执行以下命令

  cd image-build

  ./update.sh

5、安装RocketMQ控制台

// 拉取镜像

docker pull apacherocketmq/rocketmq-console:2.0.0

// 运行容器,这里172.15.65.xx为宿主机ip

docker run -e "JAVA_OPTS=-Drocketmq.namesrv.addr=172.15.65.xx:9876 -Dcom.rocketmq.sendMessageWithVIPChannel=false" -p 6881:8080 -t apacherocketmq/rocketmq-console:2.0.0

6、镜像保存

// 镜像根据私有镜像仓库重命名 并推送到私有仓库

docker tag IMAGEID(镜像id) REPOSITORY:TAG(仓库:标签)

#例子
docker tag ca1b6b825289 harbor.jiuqichina.com/public/rocketmq:4.9.3

docker push harbor.jiuqichina.com/public/rocketmq:4.9.3

【RocketMQ高可用】RocketMQ 双主双从集群搭建

一、集群架构

** 描述** NameServer 集群 NameServer 是一个无状态的节点,可集群部署,节点都是各自独立的,无任何信息同步 Broker 集群 ① Broker 分为 Master 与 Slave,一个 Master 可以对应多个 Slave,但一个 Slave 只能对应一 个Master
② Master 与 Slave 的对应关系通过制定相同的 BrokerName,不同的 BrokerID 来定义,id 为 0 表示 Master, 非 0 表示 Slave
③ 可以部署多个 Master 实现 Broker 集群,即多组 Master - Slaves 的 Broker 节点
④ Master 通常用于写入数据,Slaves 用于读取数据
⑤ 每个 Broker 与 NameServer 集群中的所有节点建立长连接,定时注册 Topic 信息到所有 NameServer
Producer 集群 ① Producer 为消息的生产者,都是各自独立的无状态的节点,可以认为只要向 mq 中推送消息的节点都算作 Producer 节点。
② Producer 节点与 NameServer 集群中的随机一个节点建立长连接,定期从 NameServer 取出 Topic 路由信息,并向提供 Topic 服务的 Master 建立长连接。且定时向 Master 发送心跳。
Customer 集群 ① Customer 为消息的消费者,都是各自独立的无状态的节点,可以认为只要向 mq 中获取消息的节点都算作 Customer 节点。
② Customer 节点与 NameServer 集群中的随机一个节点建立长连接,定期从 NameServer 取出 Topic 路由信息,并向提供 Topic 服务的 Master、Slave 建立长连接。且定时向 Master、Slave 发送心跳。
③ Customer 节点既可以从 Master 订阅消息,也可以从 Slave 订阅消息,订阅规则由 Broker 配置决定

二、四种集群模式

2.1 单 Master 模式

部署简单,但风险较大,一旦 Broker 重启或者宕机时,会导致服务不可用,不建议在线上环境使用,可以在本地测试

2.2 多 Master 模式

Broker 集群中无 Slave,全是 Master

优点:

配置简单,且单个 Master 宕机或重启维护对应用无影响,在磁盘配置为 RAID10 时,即使机器宕机不可恢复的情况下,由于 RAID10 磁盘非常可靠,消息也不会丢(异步刷盘丢失少量消息,同步刷盘一条不丢),性能最高

缺点:

单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅和消费,消费实时性会受到影响

2.3 多 Master 多 Slave 模式(异步)

每个 Master 配置一个 Slave,有多对 Master-Slave,HA 采取异步复制方式,主备有短暂消息延迟(毫秒级)。即提供者将消息发送到 Master 后,Master 即刻返回结果给提供者。同时异步复制到 Slave 中

优点:

即使磁盘损坏,丢失的消息非常少,且消息的实时性不会受到影响。且 Master 宕机后,消费者仍然可以从 Slave 消费,而且此过程对应用透明,不需要人工干预,性能同多 Master 模式几乎一样

缺点:

Master 宕机,磁盘损坏的情况下会丢失少量消息

2.4 多 Master 多 Slave 模式(同步)

每个Master配置一个Slave,有多对Master-Slave,HA采用同步双写方式,即只有主备都写成功,才向应用返回成功。即提供者将消息发送到 Master后,Master 要将这条消息同步到所有的 Slave 上,同步全部完成后,才会返回结果给提供者。

优点:

数据与服务都无单点故障,在 Master 宕机的情况下消息无延迟,服务可用性与数据可用性都非常高

消息安全高,高可用性

缺点:

性能比异步复制模式略低(约低10%左右),发送单个消息的RT会略高,且在主节点宕机后,备机不能自动切换为主机,需要人为干涉

三、双主双从集群搭建

3.1 总体架构图

双主双从集群(2m-2s)同步双写方式,即使用两组 Master-Slave 形成集群

3.2 工作流程

1)启动NameServer,NameServer起来后监听端口,等待Broker、Producer、Consumer连上来,相当于一个路由控制中心。

2)Broker启动,跟所有的NameServer保持长连接,定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后,NameServer集群中就有Topic跟Broker的映射关系。

3)收发消息前,先创建Topic,创建Topic时需要指定该Topic要存储在哪些Broker上,也可以在发送消息时自动创建Topic。

4)Producer发送消息,启动时先跟NameServer集群中的其中一台建立长连接,并从NameServer中获取当前发送的Topic存在哪些Broker上,轮询从队列列表中选择一个队列,然后与队列所在的Broker建立长连接从而向Broker发消息。

5)Consumer跟Producer类似,跟其中一台NameServer建立长连接,获取当前订阅Topic存在哪些Broker上,然后直接跟Broker建立连接通道,开始消费消息。

3.3 双主双从集群搭建流程

在实际工作中,应只对外暴露需要被外部访问的端口。

本次部署采用两台服务器搭建:

序号 IP 角色 架构模式 server01 192.168.1.206 nameserver、broker-a、broker-b-s Master1、Slave2 server02 192.168.1.199 nameserver、broker-b、broker-a-s Master2、Slave1

创建配置存储路径:

注意:logs 目录和store目录的权限 否则会启动不成功

server01:

mkdir -p data/{broker-a/conf,broker-a/logs,broker-a/store,broker-b-s/conf,broker-b-s/logs,/broker-b-s/store}

server02:

mkdir -p data/{broker-b/conf,broker-b/logs,broker-b/store,broker-a-s/conf,broker-a-s/logs,/broker-a-s/store}

1)Master01配置(192.168.1.206)

2)Master02配置(192.168.1.199)

3.4 启动集群

打开dashboard地址(http://192.168.1.206:6881/)查看:

参考文档:

​ https://blog.csdn.net/qq_34416331/article/details/107336391