Loading... # 消息中间件之RocketMQ(四) ## RocketMQ 集群 **单Master模式** 只有一个Master节点。 优点: 配置简单，方便部署。 缺点: 这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用，不建议线上环境使用。 **多Master模式** 一个集群，没有Slave，全是Master，例如2个Master或者3个Master 优点: 配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢(异步刷盘丢失少量消息，同步刷盘一条不丢)。 缺点: 单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。 **多Master多Slave模式(异步复制)** 每个Master配置一个Slave，有多对Master-Slave，HA，采用异步复制方式，主备有短暂消息延迟，毫秒级。 优点: 即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master宕机后，消费者仍然可以从Slave消费，此过程对应用透明。不需要人工干预，性能同多Master模式几乎一样。 缺点: Master宕机，磁盘损坏情况，会丢失少量消息。 **多Master多Slave模式(同步双写)** 每个Master配置一个Slave，有多对Master-Slave，HA，采用同步双写方式，主备都写成功，向应用返回成功。 优点: 数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高。 缺点: 性能比异步复制模式略低，大约低10%左右，发送单个消息的RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。 ![webp2.jpg][1] ### 双主双从集群搭建 #### 准备 1. 4台虚拟机 2. 配置好网络 3. 准备好RocketMQ服务端程序 #### 启动NameServer 4台机器分别启动 #### Broker配置 Broker Configuration | Property Name | Default Value | Details | | :-: | :-: | :-: | | listenPort | 10911 | listen port for client | | namesrvAddr | null | name server address | | brokerIP1 | InetAddress for network interface | Should be configured if having multiple addresses | | brokerName | null | broker name | | brokerClusterName | DefaultCluster | this broker belongs to which cluster | | brokerId | 0 | broker id, 0 means master, positive integers mean slave | | storePathCommitLog | $HOME/store/commitlog/ | file path for commit log | | storePathConsumerQueue | $HOME/store/consumequeue/ | file path for consume queue | | mapedFileSizeCommitLog | 1024 * 1024 * 1024(1G) | mapped file size for commit log | | deleteWhen | 04 | When to delete the commitlog which is out of the reserve time | | fileReserverdTime | 48 | The number of hours to keep a commitlog before deleting it | | brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE | | flushDiskType | ASYNC_FLUSH | {SYNC_FLUSH/ASYNC_FLUSH}. Broker of SYNC_FLUSH mode flushes each message onto disk before acknowledging producer. Broker of ASYNC_FLUSH mode, on the other hand, takes advantage of group-committing, achieving better performance | brokerClusterName: 同一个集群中，brokerClusterName需要一致 brokerId: 0表示Master，大于0表示Slave namesrvAddr: NameServer地址，多个用';'分隔 brokerIP1: 默认系统自动识别，但是某些多网卡机器会存在识别错误的情况，建议都手工指定 brokerRole: 选择Brokker的角色(异步复制、同步双写、Slave) flushDiskType: 选择刷盘方式(同步刷盘、异步刷盘) deleteWhen: 过期文件真正删除时间，24小时制，默认凌晨4点 fileReservedTime: CommitLog、ConsumeQueue文件，如果非当前写文件，在设置的时间间隔内(4.6+默认48小时)没有再次被更新(文件最终修改时间)，则认为是过期文件，可以被删除，RocketMQ不会管这个文件上的消息是否被全部消费。 由配置就可以看出，区别Master和Slave是通过brokerId，这是在配置中写死的，也就是说，如果Master宕机了，Slave也不会晋升成Master，只能等待Master重新上线，或者手动修改Slave的配置。 RocketMQ已经提供了集群的配置模板,在conf目录中 2m-2s-async: 2主2从，异步复制模板 2m-2s-sync: 2主2从，同步双写模板 2m-noslave: 2主，没有从节点的模板 以2主2从，异步复制模板为例 进入2m-2s-async文件夹 broker-a.properties: broker-a主节点配置 broker-a-s.properties: broker-a从节点配置 broker-b.propertiesL: broker-b主节点配置 broker-b-s.properties: broker-b从节点配置 第一台虚拟机 vi broker-a.properties ``` brokerClusterName=DefaultCluster # 集群名 4台虚拟机要设置相同 brokerName=broker-a # broker名称 主从之间需要相同 多个Master之间需要配置不同的 brokerId=0 # brokerId 0 表示Master deleteWhen=04 # 过期文件删除时间 fileReservedTime=48 # 多长时间不更新算过期 brokerRole=ASYNC_MASTER # 角色 异步复制主节点 flushDiskType=ASYNC_FLUSH # 刷盘方式 异步刷盘 ``` 第二台机器修改broker-a-s.properties ``` brokerClusterName=DefaultCluster brokerName=broker-a brokerId=1 # 区别 大于0 表示Slave deleteWhen=04 fileReservedTime=48 brokerRole=SLAVE # 角色 Slave flushDiskType=ASYNC_FLUSH ``` 另外两台修改broker-b的配置文件 在所有配置文件中添加NameServer地址: ``` namesrvAddr=192.168.50.19:9876;192.168.50.20:9876;192.168.50.21:9876;192.168.50.22:9876 ``` 然后分别以不同的配置文件启动4个Broker ``` mqbroker -c ../conf/2m-2s-async/broker-a.properties ``` ### 主备切换 故障转移模式 ![watermark.jpg][2] 在RocketMQ4.5版本之前，只有Master/Slave一种部署方式，一组Broker中有一个Master，有零到多个Slave。Slave通过同步双写或异步复制的方式去同步Master数据。Master/Slave部署模式，提供了一定的高可用性，但这样的部署模式有一定的缺陷，比如，故障转移方面，如果主节点挂了，还需要人为手动进行重启或者切换，无法自动将一个从节点转换为主节点。因此，我们希望有一个新的多副本架构，去解决这个问题。新的多副本架构首先需要解决自动故障转移的问题，本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种: 1. 利用第三方协调服务集群完成选主，比如zookeeper或者etcd(raft)。这种方案会引入重量级外部组件，加重部署、运维和故障诊断成本，比如在维护RocketMQ集群还需要维护zookeeper集群，并且zookeeper集群故障会影响到RocketMQ集群。 2. 利用raft协议来完成一个自动选主，raft协议相比前者的优点是不需要引入外部组件，自动选主逻辑集成到各个节点进程中，节点之间通过通信就可以完成选主。 #### DLeger RocketMQ实现的基于raft协议自动选主程序，实际上是通过启动一个线程完成的。该方案至少需要3台服务器做集群，也就是1主2备，否则无法提供选举，因为raft是基于PAXOS协议实现的，需要满足过半原则。 Broker配置 ``` # dleger enableDLegerCommitLog = true # 开启DLedger dLegerGroup = broker-a # brokerName 主从相同 dLegerPeers = n0-192.168.150.210:40911;n1-192.168.150.211:40911;n2-192.168.150.212:40911 # DLedger集群的所有节点 默认端口40911 dLegerSelfId = n0 # 当前机器的DLegerId，也就是dLegerPeers配置的n几 sendMessageThreadPoolNums = 4 # DLeger之间通信的线程数 建议设置为cpu核心数 ``` 在集群中的所有节点添加如上配置。启动Broker，就完成了主备集群，Master宕机，会自动从Slave中选取一个晋升成Master。 ### Topic中的Queue分布 在实际使用中，多Master下，自动创建Topic会随机选择一个Master，然后在其中创建4个Queue(默认4个)，也就是说，一个Topic的所有Queue都会创建在一个Broker里，如果想再每个Broker中都创建的话，就需要手动执行。 #### 手动创建Topic 手动创建可以使用Console在UI界面中创建，比较简单方便。但是该方式每次Update都会覆盖之前的配置，而且每次操作，都会执行到所有的Master中，也就是我想在A中放两个，在b中放三个是做不到的，只能都放两个，或者都放三个。想实现更多的细节和更好的功能，在生产环境中，通常会使用MQAdmin工具。 命令: ``` [root@node-01 bin]# ./mqadmin updateTopic usage: mqadmin updateTopic -b <arg> | -c <arg> [-h] [-n <arg>] [-o <arg>] [-p <arg>] [-r <arg>] [-s <arg>] -t <arg> [-u <arg>] [-w <arg>] -b,--brokerAddr <arg> create topic to which broker -c,--clusterName <arg> create topic to which cluster -h,--help Print help -n,--namesrvAddr <arg> Name server address list, eg: 192.168.0.1:9876;192.168.0.2:9876 -o,--order <arg> set topic's order(true|false) -p,--perm <arg> set topic's permission(2|4|6), intro[2:W 4:R; 6:RW] -r,--readQueueNums <arg> set read queue nums -s,--hasUnitSub <arg> has unit sub (true|false) -t,--topic <arg> topic name -u,--unit <arg> is unit topic (true|false) -w,--writeQueueNums <arg> set write queue nums ``` 示例: ``` ./mqadmin updateTopic -b 192.168.50.19:10911 -t shoudongchuangjian02 -r 1 -w 1 -n 192.168.50.19:9876 ``` 在192.168.50.19中创建一个名为shoudongchuangjian02的Topic，并为其创建一个读队列一个写队列(逻辑上就是一个读写队列)。注意，指定的Broker必须是Master节点，否则虽然执行成功，但是不会创建Topic。 [1]: https://www.princelei.club/usr/uploads/2020/07/2245416977.jpg [2]: https://www.princelei.club/usr/uploads/2020/07/1608497316.jpg Last modification：November 27th, 2020 at 11:00 pm © 允许规范转载
