走进 RocketMQ- 部署模式与实战
前言
Halo，我是白裤。
上一次我们学习了 RocketMQ 的整体架构与设计，了解了 RocketMQ 的整体架构、模型设计以及它的一个工作流程，今天我们将学习 RocketMQ 的几种部署模式，并且实际动手进行 Dledger 模式的部署，让我们开始学习吧。
部署模式
首先在部署实战前，我们先简单来看看 RocketMQ 的几种部署方式，其中包括了单点模式、多主模式、多主多从模式（异步复制）、多主多从（同步双写）、Dledger 模式，每种部署方式都有其比较明显的特点，我们要了解清楚这些部署模式的优缺点，这样我们在生产环境中就可以去选择适合自己业务需求的一个方案。
1.单点模式
单点模式就是单独部署一个节点，主要是本地测试使用，一般不会用于生产环境的部署，因为单点大家都知道风险是很大的，如果宕机，则整个服务将会处于不可用状态，大家生产环境还是建议不要使用这种模式哦，不过有勇敢的兄弟想尝试也不是不行，我只能告诉你：试试就逝世。
优点
部署简单，一个节点直接启动搞定完事。
缺点
单点挂掉的时候会停止提供服务，一挂你这个月的绩效可能就 GG 了。
2.多主模式
多主模式其实就是部署多个节点，每个节点都支持读写操作，也没有从节点啥的，就是各自不互相影响的多个节点。
优点
部署也相对简单，单独启动多个节点即可，即使某个节点宕机了，也不会影响整个应用的运行与服务提供。
缺点
某个节点宕机的话，在这个节点上的消息可能不能实时地进行消费，这点需要注意。
3.多主多从模式（异步复制）
多主多从（异步复制）就是部署的时候，每个 Master 节点配置一个 Slave 节点，有多对 Master 和 Slave，Master 消息数据会以异步的方式复制给 Slave，当 Master 宕机的时候消费者还可以从 Slave 读取消息，从而对消息的消费不会产生较大的影响，由于 Master 和 Slave 之间呢是用异步复制的方式来进行数据同步的，所以消息的实时性可能不能很好的保证，即存在延迟，同时当 Master 宕机的时候可能会丢失消息。
优点
在有 Slave 的备用节点下，当 Master 宕机时，消费者仍然可以从 Slave 处消费消息，这样不会影响到消息的消费，这个过程是 RocketMQ 自己去处理的。
缺点
当 Master 宕机时，磁盘如果损坏会有消息丢失的情况，虽然可以从 Slave 消费消息，但是分配在该 Master 节点上的队列接收不了消息的生产。
4.多主多从模式（同步双写）
多主多从（同步双写）模式指的是每个 Master 节点配置一个 Slave 节点，有多对 Master 和 Slave，消息在生产到 Master 的时候会以同步的方式将消息数据写到 Slave 上，当 Master 和 Slave 都写入成功后消息才真正写入成功，由于是同步的，所以 Master 和 Slave 的数据没有延迟的问题，不过正因为是同步存储，所以在性能上会有所降低。
优点
同步双写可以保证数据不丢失，数据的可靠性高。
缺点
首先在性能上同步双写比异步复制要低，另外，Master 宕机后，Slave 是不会自动切换为 Master 的。
5.Dledger 模式（自动主从切换）
Dledger 模式是每个 Broker 组部署奇数台节点，比如三个节点，其中包括一个 Master 和两个 Slave 节点，数据在写入 Master 节点时，会推送给其他 Slave 节点，以此来保证数据的一致性，当 Master 节点宕机时，Dledger 会通过 Raft 协议从 Slave 节点中选举出一个新的 Master 节点继续对外提供服务，从而保证 Broker 的高可用。
优点
多节点数据同步保证了数据的可靠性，自动主从切换保证了服务的高可用性。
缺点
这个部署方式相对来说没有啥太大的缺点问题，可能在性能上相对于主从模式有些许的降低，不过 Dledger 模式在 4.8.0 版本之后使用了 Pipeline 模式和批量复制，性能已经有了很大的提升。
部署实战
在了解了 RocketMQ 的几种部署方式之后，我们来开始动手试着自己去部署一个 RocketMQ 集群，通过上面的几种部署方式的了解，我们知道 Dledger 这种模式其实是很好的一种部署方案，我们接下来将带着大家去试着部署这样一种模式的集群。
环境准备
三台服务器（131、132、133）
RocketMQ Binary 包
JDK1.8.0 环境
操作步骤
JDK 安装
分别在三台机器上面安装 JDK
1.查看安装包
2.安装对应版本的包
3.检查安装结果
RocketMQ 部署
部署准备
首先我们到官网下载 RocketMQ Binary 包，下载地址：
然后我们选择一个版本进行下载就可以了，这里我们选择的是 4.9.2 的版本进行部署测试。
1.在三台机器上面/usr/local 目录下创建 rocketmq 文件夹：
2.将下载的安装包上传至/usr/local/rocketmq 目录下：
3.解压 rocketmq-all-4.9.2-bin-release.zip 包到当前目录下：
NameServer 部署
之前我们讲过 NameServer 是彼此之间不通信的，所以我们需要在三台机器上都启动 NameServer 来构成 NameServer 集群。
1.进入/usr/local/rocketmq/rocketmq-4.9.2/bin 目录下：
2.启动 NameServer：
3.查看 NameServer 启动结果：
由于 NameServer 默认端口是 9876，所以我们可以通过查看端口 9876 来确定：
亦或者我们可以通过查看 Java 进程来查看：
我们在启动 NameServer 时需要注意一点的是启动的 JVM 参数，需要根据机器的信息来进行调整，这里 NameServer 启动的参数我们可以在/usr/local/rocketmq/rocketmq-4.9.2/bin 目录下的 runserver.sh 文件里面自行修改即可
Broker 部署
由于我们是 Dledger 模式部署，所以一组 Dledger 组至少需要三个节点，一个 Master 节点两个 Slave 节点，所以我们分别在三台机器上部署一个节点来组成一个 Dledger 组。
首先我们来看下 Broker 的配置文件：
我们可以看到有上面我们介绍的几种模式，2m-2s-async 表示两主两从异步复制模式，2m-noslave 表示两主无从模式，2m-2s-sync 代表两主两从同步双写模式，而我们此次部署的 dledger 模式的配置文件则在 dledger 目录下了。
接下来，我们进入到 dledger 目录下，可以看到有三个配置文件：
我们在三台机器上面分别修改 Broker 的配置文件：
131 机器上面修改 broker-n0.conf 文件：
132 机器上面修改 broker-n1.conf 文件：
133 机器上面修改 broker-n2.conf 文件：
注意：上面配置文件中的 xxx.xxx.xxx.xxx 为你的服务器地址
接下来我们分别启动三台机器上的 Broker 节点：
第一台机器
进入 bin 目录：
启动 Broker：
第二台机器
进入 bin 目录：
启动 Broker：
第三台机器
进入 bin 目录：
启动 Broker：
我们在确认完三台机器的 Broker 都启动正常的情况下，我们在其中一台机器上看下整个 Dledger 集群的节点状态：
首先进入 bin 目录：
执行一下命令查看集群状态：
结果如下：
我们可以看到三个 Broker 节点已经组成一个 Dledger 组，其中 BID 为 0 的为 Master 节点，其余为 Slave 节点。
容灾测试
接下来我们来测试一下 Dledger 的主从自动切换容灾功能：
进入 BID=0 的节点机器，将 Broker 停掉：
然后我们再看看 Broker 集群状态：
可以看到，此时 BID=0 的节点为 133 机器节点，一开始我们的 Master 节点是 132 的机器节点，现在 132 节点被 shutdown 后，RocketMQ 自动将 133 节点切换成了 Master 节点，证明 Dledger 模式是拥有实现主从自动切换容灾的功能的。
我们再把 132 的 Broker 启动起来：
可以看到，132 机器的 Broker 正常加入到了集群中，至此，我们的整个基于 Dledger 模式的部署已经完成。
小结
我们通过对 RocketMQ 几种部署模式的了解，知道了几种模式的不同特点，同时，我们自己动手部署了一套基于 Dledger 模式的 RocketMQ 集群，并验证了 Dledger 模式下的主从自动切换容灾功能，让我们对 RocketMQ 又有了进一步的了解。
好了，今天我们就学习到这里，下一次我们将学习 RocketMQ 消息的存储与消费是如何设计的。
版权声明: 本文为 InfoQ 作者【白裤】的原创文章。
原文链接:【http://xie.infoq.cn/article/352ee4d1d342734a747706eff】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2021-04-25 加入
一个很懒的人
评论