本文承接《RocketMQ 分布式消息中间件 理论介绍》
RocketMQ 集群部署模式
- 如上图所示, RocketMQ的部署结构有以下特点:
- Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。
- Broker 部署相对复杂,Broker 分为 Master 与 Slave,一个 Master(主人) 可以对应多个 Slave(奴隶),但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的 BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个,每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic 信息到所有 Name Server。
- Producer 与 Name Server 集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供 Topic 服务的 Master 建立长连接,且定时向 Master 发送心跳。Producer完全无状态,可集群部署。
- Consumer 与 Name Server 集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供 Topic 服务的 Master、Slave 建立长连接,且定时向 Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
单 master 模式
- 也就是只有一个 master 节点,称不上是集群,一旦这个 master 节点宕机,那么整个服务就不可用,适合个人学习使用。
多 master 模式
- 多个 master 节点组成集群,单个 master 节点宕机或者重启对应用没有影响。
- 优点:所有模式中性能最高
- 缺点:单个 master 节点宕机期间,未被消费的消息在节点恢复之前不可用,消息的实时性就受到影响。
- 注意:使用同步刷盘可以保证消息不丢失,同时 Topic 相对应的 queue 应该分布在集群中各个节点,而不是只在某各节点上,否则,该节点宕机会对订阅该 topic 的应用造成影响。
多 master 多 slave 异步复制模式
- 在多 master 模式的基础上,每个 master 节点都有至少一个对应的 slave。
- master 节点可读可写,但是 slave 只能读不能写,类似于 mysql 的主从模式。
- 优点: 在 master 宕机时,消费者可以从 slave 读取消息,消息的实时性不会受影响,性能几乎和多 master 一样。
- 缺点:使用异步复制的同步方式有可能会有消息丢失的问题。
多 master 多 slave 同步双写模式
- 同多 master 多 slave 异步复制模式类似,区别在于 master 和 slave 之间的数据同步方式。
- 优点:同步双写的同步模式能保证数据不丢失。
- 缺点:发送单个消息 RT 会略长,性能相比异步复制低10%左右。
- 刷盘策略:同步刷盘和异步刷盘(指的是节点自身数据是同步还是异步存储)
- 同步方式:同步双写和异步复制(指的一组 master 和 slave 之间数据的同步)
- 注意:要保证数据可靠,需采用同步刷盘和同步双写的方式,但性能会较其他方式低。