小红书网站建设内容产品推广的渠道

        根据上一章《RocketMQ消费模型和部署模型》得知，启动rocketmq非常简单，只需要分别执行mqnamesrv启动NameServer，执行mqbroker启动Broker即可。但生产环境不可能仅使用单节点MQ，为提高可用性和吞吐量，生产常使用集群模式部署。本章节将详述Rocketmq集群模式部署方式。

1，预期的集群架构

        ​

        如上图，通过三台MQ服务器，配置成2主2从集群架构。服务器1只用来部署一个NameServer，所以也可以配置成3主3从的架构。发布者和消费者可通过业务系统的集群部署增加吞吐量。

        NameServer是无状态的，且相互间无需沟通，也就是说，每个NameServer的等级和数据是相同的，Broker可与任意NameServer连接。

        Broker的主从分布在不同机器上，保证了数据安全性，当某个机器故障，每个Broker至少有一个节点存储的有数据，减少数据的丢失（非100%数据安全，未同步到从节点的数据仍会丢失）

2，部署步骤

        2.1，修改配置

        修改NameServer配置：        

        修改服务器1,2,3上的 runserver.sh，根据机器内存修改JVM参数。如下图：

        默认是4G，根据JDK版本，当前机器使用JDK11，虚拟机内存为2G，故只分配256M

        修改主从Broker配置：

        同样需要先修改runbroker.sh的JVM参数，不再赘述，可见上章节。

        主从文件修改，根据官方提供的sample修改。为保证环境干净，复制2m-2s-async至my-2m-2s-async。修改服务器2上的broker-a.properties，如下图：

        同理，配置服务器3上的broker-a-s.properties，如下图：

        broker-b.properties，broker-b-s.properties与broker-a.properties和broker-a-s.properties修改内容一致，仅brokerName不一样。注意：新增的几个日志文件位置，需要主从路径分开，本人因想当然放在一起，困扰好几天无法正常启动服务。

        2.2，启动服务

        机器2启动Broker-a和Broker-b-s，机器3启动Broker-b和Broker-a-s

        同理启动其他Broker，启动后查看服务如下：

        至此，Rocketmq的2m-2s的集群架构已搭建完成。

3，RocketMQ集群架构问题

        在集群架构下，producer发送的消息都只发送给master，slave节点只是用来存储数据，保证数据安全。若master所在机器故障，Rocketmq并不会主动将slave升级为master对外提供服务。也就是说，如果上述案例中机器2故障，则机器2上的broker-a的master无法接收消息，虽然机器3运行正常，但机器3上的broker-a-s也无法接收消息。在机器2重新启动之前，发送至Broker-a的消息都将发送失败。

        为解决上述问题，RocketMQ提供了dleger部署方式，各broker间自动选举出leader和follwer，正常情况下，leader用于对外提供服务，follwer用于备份数据。当leader发生故障，通过Raft协议(多数同意机制)，自动选举出新的leader对外提供服务。该部署模式在5.0版本变动较大，后续直接详解5.0版本。