RocketMQ4.X 集群

RocketMQ4.X 多种集群模式

单节点 ：

• 优点：本地开发测试，配置简单，同步刷盘消息一条都不会丢
• 缺点：不可靠，如果宕机，会导致服务不可用

主从(异步、同步双写) ：

• 优点：同步双写消息不丢失， 异步复制存在少量丢失 ，主节点宕机，从节点可以对外提供消息的消费，但是不支持写入
• 缺点：主备有短暂消息延迟，毫秒级，目前不支持自动切换，需要脚本或者其他程序进行检测然后进行停止 Broker，重启让从节点成为主节点

双主：

• 优点：配置简单， 可以靠配置 RAID 磁盘阵列保证消息可靠，异步刷盘丢失少量消息
• 缺点： master 机器宕机期间，未被消费的消息在机器恢复之前不可消费，实时性会受到影响

双主双从，多主多从模式（异步复制）

• 优点：磁盘损坏，消息丢失的非常少，消息实时性不会受影响，Master 宕机后，消费者仍然可以从 Slave 消费
• 缺点：主备有短暂消息延迟，毫秒级，如果 Master 宕机，磁盘损坏情况，会丢失少量消息

双主双从，多主多从模式（同步双写）

• 优点：同步双写方式，主备都写成功，向应用才返回成功，服务可用性与数据可用性都非常高
• 缺点：性能比异步复制模式略低，主宕机后，备机不能自动切换为主机

推荐方案2、4、5

什么是同步刷盘和异步刷盘?

刷盘的意思是将消息从内存中写到磁盘中，同步刷盘是指在获取消息后立马将消息写到磁盘中，异步刷盘是指获取消息后根据策略将消息写到磁盘中。

什么是消息的同步复制和异步复制？

同步复制是指主节点接收到消息后立刻复制给从节点，所有从节点都接收到消息后，才算是真的接收到消息。

异步复制是指主节点接收到消息后就算接收到消息，之后根据策略复制给从节点。

最终推荐这种方式：同步双写(同步复制)，异步刷盘

使用 RocketMQ4.X 搭建主从节点

本文 RocketMQ 的安装过程参照这篇文章：https://www.cnblogs.com/jwen1994/p/12318575.html

RocketMQ 提供了多种集群配置文件方便我们配置自己想要的集群，我们要做的就是修改配置文件，然后指定配置文件启动 Broker。

在这里我新建了两台虚拟机，安装一模一样的环境。主节点 IP 地址：192.168.0.107，从节点 IP 地址：192.168.0.104

注意：1、不要安装一台然后克隆，我之前采用这样的方式，一直失败，之后我重新安装了一台虚拟机就可以了。2、一定要关闭防火墙：systemctl stop firewalld

我们修改这两个文件：broker-a.properties 和 broker-a-s.properties

主节点修改为：

namesrvAddr=192.168.0.107:9876;192.168.0.104:9876
brokerClusterName=XdclassCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

从节点修改为：

namesrvAddr=192.168.0.107:9876;192.168.0.104:9876
brokerClusterName=XdclassCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH

启动服务：先启动 namesrv，然后启动 broker，关闭时，先关闭 broker，再关闭 namesrv

主节点启动 broker：

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &

从节点启动 broker：

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &

用主节点启动控制台观察集群情况

 

主从同步必备知识点

1、Broker 分为 master 与 slave，一个 master 可以对应多个 slave，但一个 slave 只能对应一个 master，master 与 slave 通过相同的 Broker Name 来匹配，不同的 broker Id 来定义是 master 还是 slave

• Broker 向所有的 NameServer 结点建立长连接，定时注册 Topic 和发送元数据信息
• NameServer 定时扫描(默认2分钟)所有存活 Broker 的连接, 如果超过时间没响应则断开连接(心跳检测)，但是 consumer 客户端不能感知，consumer 定时(30s)从 NameServer 获取 Topic 的最新信息，所以 Broker 不可用时，consumer 最多最需要30s才能发现（Producer 的机制也是一样，在未发现 Broker 宕机前发送的消息会失败）

2、只有 master 才能进行写入操作，slave 不允许写入只能同步，同步策略取决于 master 的配置。

3、客户端消费可以从 master 和 slave 消费，默认消费者都从 master 消费，如果在 master 挂后，客户端从 NameServer 中感知到 Broker 宕机，就会从 slave 消费, 感知非实时，存在一定的滞后性，slave 不能保证 master 的消息100%都同步过来了，会有少量的消息丢失。但一旦 master 恢复，未同步过去的消息会被最终消费掉。

4、如果 consumer 实例的数量比 message queue 的总数量还多的话，多出来的 consumer 实例将无法分到 queue，也就无法消费到消息，也就无法起到分摊负载的作用，所以需要控制让 queue 的总数量大于等于 consumer 的数量。