RocketMQ的各种集群模式的搭建和消息可靠性保证和服务可用性描述

RocketMQ集群搭建的特点

1. NameServer是一个几乎无状态的节点，可直接启动集群部署。节点之间没有任何信息同步，并且集群的NameServer之间都不知道彼此的存在。
2. Broker部署相对复杂，Broker分为Master和Slaver，一个Master对应多个Slaver，一个Slaver只能对应一个Master，Master和Slaver的对应关系通过指定相同的Broker Name、不同的Broker Id确定，Broker Name相当于集群组名，相同名称Broker表示是同一个集群组。Broker Id 相当于同一集群组里面Broker节点的唯一标志。Broker Id 为0的节点表示Master节点。非0的节点表示Slaver节点。Master也可以部署多个。每个Broker与NameServer集群中的所有NameServer节点都建立长连接（实际上是启动时指定的NameServer节点，不一定是全部，但是理应是全部），定时注册Topic信息到每一个NameServer节点。这里不像主从集群那样，先把Topic信息注册到Master中，再由Master进行同步，而是直接往所有节点里面同步。所以NameServer节点之间无需通信，甚至不知道对方的存在。
   注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。也就是实际上进行消息消费的Broker节点只有Master和一号Slaver，多余的Slaver顶多具有热备份容灾的效果。
3. Producer与NameServer集群中的一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供服务的Master节点Broker建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
4. Consumer与NameServer集群中的一个节点（随机选择）建立长连接，定期从NameServer中获取Topic路由信息，并向提供服务的Master、Slaver节点的Broker建立长连接，并且定时向Master和Slaver发送心跳。Consumer既能从Master中订阅消息，也可以从Slaver中订阅消息。消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。

集群工作流程

1. 启动NameServer，NameServer启动后监听端口，等待Broker、Producer、Consumer启动后连接上来，相当于一个路由控制中心。
2. Broker启动，跟所有NameServer建立长连接，并定时发送心跳包。心跳包包含的信息有当前Broker的信息（IP、Port等）和存储所有Topic信息。注册成功后，NameServer中就有Topic和Broker的映射关系信息。
3. 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
4. Producer启动并与其中一个NameServer建立长连接，然后发送消息，发送消息时，要根据从NameServer中获取到的Topic与Broker的映射关系信息，再根据自己要发送的消息的Topic确定有哪些Broker，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。

集群模式分类

RocketMQ有四种集群模式。

单Master模式

这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。

搭建方法：https://blog.csdn.net/qq_40837310/article/details/107409912

多Master模式

一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：

• 优点：配置简单，单个Master宕机或者重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
• 缺点：因为集群中的每台Master节点的消息数据是不一样的。消息是分布在这些节点之中。所以单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

这个集群的搭建方法跟单Master的搭建方法一样。只是在多个机器实例上启动多个Broker，并且注册到同一组NameServer集群中就行。

多Master多Slave模式-异步复制模式

每个Master配置一个Slaver，也可以多个Slaver，有多对Master-Slaver，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

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

一般建议一台Master一台Slaver组合，然后多对这样的组合组成一个集群，因为只有Broker ID 为1的Slaver节点才会进行读负载（消费），如果你启动了一台Master多台Slaver，只是在不提升消费性能的情况下降低了写（生产消息）的性能，因为要进行多台机器的同步，耗时会比只跟一台Slaver机器同步的时候要高。

搭建方法：

1. 进入RocketMQ目录的conf目录，ROCKETMQ_HOME/conf
   
   红框中的文件夹就是一主一从，然后两组这个组合的集群的默认配置文件夹，如果你要搭建的是这个组合的集群，可以直接用里面的配置文件来启动Broker即可。

broker-a.properties是 broker-a的master节点

broker-a-s.properties 是broker-a的Slaver节点。

broker-a.properties文件：

• brokerName与broker-a-s.properties的brokerName要一致。代表是同一组。
• 因为是master节点，所以brokerId要为0。
• brokerRole属性：指定Broker角色，值为ASYNC_MASTER、SYNC_MASTER、SLAVE，分别是异步复制master、同步复制Master，Slave。
• flushDiskType：配置刷盘方式，ASYNC_FLUSH表示异步刷盘，SYNC_FLUSH表示同步刷盘。

首先启动NameServer

nohup sh mqnamesrv &

先启动Master的Broker节点再启动Slaver：

//### 在机器A，启动第一个Master，NameServer的IP为：192.168.18.137
nohup sh mqbroker -n 192.168.18.137:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties &

//### 在机器B，启动第二个Master，NameServer的IP为：192.168.18.137
nohup sh mqbroker -n 192.168.18.137:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties &

//### 在机器C，启动第一个Slave，NameServer的IP为：192.168.18.137
 nohup sh mqbroker -n 192.168.18.137:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties &

//### 在机器D，启动第二个Slave，NameServer的IP为：192.168.18.137
nohup sh mqbroker -n 192.168.18.137:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &

如果想要再配置多组master-Slaver组合，可以把配置文件内容复制，只需修改brokerName属性，然后启动就行。

多Master多Slave模式-同步双写

每个Master配置一个Slave，也可以多个，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

• 优点：数据与服务都无单点故障（因为数据时同步复制的），Master宕机情况下，消息无延迟（因为主备要复制成功才返回，所以不存在主备消息延时），服务可用性与数据可用性都非常高；
• 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

搭建方式：

1. 进入RocketMQ目录的conf目录，ROCKETMQ_HOME/conf
   
   红框中的文件夹就是一主一从，然后两组这个组合的集群的默认配置文件夹，如果你要搭建的是这个组合的集群，可以直接用里面的配置文件来启动Broker即可。

broker-a.properties文件：

与上面的异步复制集群的唯一区别就是brokerRole属性为SYNC_MASTER。

启动方式与异步复制集群集群一样，只是使用的配置文件不一样。

以上Broker与Slave配对是通过指定相同的BrokerName参数来配对，Master的BrokerId必须是0，Slave的BrokerId必须是大于0的数。另外一个Master下面可以挂载多个Slave，同一Master下的多个Slave通过指定不同的BrokerId来区分。

消息可靠性

消息可靠性是RocketMQ很重要的特性之一。RocketMQ能够支持消息的高可靠。

1. Broker非正常关闭
2. Broker异常Crash
3. OS Crash
4. 机器掉电，但是能立即恢复供电情况
5. 机器无法开机（可能是cpu、主板、内存等关键设备损坏）
6. 磁盘设备损坏

1、2、3、4 四种情况都属于硬件资源可立即恢复情况，RocketMQ在同步刷盘情况下可以保证在这四种情况下能消息不丢，在异步刷盘情况下可能会丢失少量消息，因为刷盘是异步的，在还没刷盘之前宕机，没有进行刷盘的消息就会丢失。

5、6属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过主从集群模式，比如一主一从，一主多从，多主多从，再配合主从之间同步复制，可以完全避免在这两种情况下消息丢失，如果是主从之间异步复制的话，可能会丢失少量消息，因为主从之间复制是异步的，如果还没来得及复制主机就坏了，就会丢失没来得及复制的消息。

服务高可用性

1. 在单点master模式下，如果节点宕机，就无法对外提供服务。
2. 在1主n从的模式下，如果主节点挂机，就无法对外提供写服务，只能提供读（消费服务）。因为从服务器能够承担读服务。消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
3. 多主无从模式下，如果某个master节点宕机，那么该节点上的数据就暂时无法消费，但是消息发送对外仍然可用，对应用透明，因为可以把原本路由到该节点的消息路由到其他正常的master节点。
4. 多主多从的模式下，如果某个主节点宕机，对外仍然能提供正常的读写服务，因为宕机的master节点他的slave节点能够提供给消费者消费消息，把原本路由到该节点的消息路由到其他正常的master节点。所以这种情况下RocketMQ的可用性非常高。

多主集群的queue分布：

RocketMQ不像kafka那样，kafka分区在多个节点中时均衡分配的，比如某个topic有3个分区，有三个kafka节点，那么就每个节点分配一个分区，而RocketMQ假如topic有4个queue，有2个master节点，那么会根据节点的配置来分配节点，比如测试时有2个master节点，4个分区，一个master的堆内存设置为512m，另一个为256m，反正是另一个的2倍，那么创建topic时，四个分区，1、2、4分区在第一个master节点，2、3分区在第二个master节点。后来我把两个节点的配置调成一样，都是512m，此时a节点1、2、3、4分区，b节点也是1、2、3、4分区。
完结。