RocketMQ的高可用集群部署

RocketMQ的高可用集群部署

标签（空格分隔）： 消息队列 部署

---

1. RocketMQ 集群物理部署结构

Rocket 物理部署结构

Name Server: 单点,供Producer和Consumer获取Broker地址, 类似于注册中心.
Producer: 产生并发送消息.
Consumer: 接收并消费消息.
Broker: 消息暂存,消息转发.

1.1 Name Server

Name Server做的是Rocket的寻址服务, 用于将Broker的路由信息做聚合. 客户端依靠Name Server决定去获取对应topic的路由信息,从而决定对那些Broker做链接.

Name Server是一个几乎无状态的节点, Name Server之间采用Share-Nothing的设计, 互不通信.

对于一个Name Server集群列表, 客户端链接Name Server的时候会随机选择一个节点, 以做到负载均衡.

Name Server所有状态都从Broker上报上来, 本身不存储任何状态, 所有数据均在内存.

如果中途所有的Name Server都挂了, 只会影响到路由信息的更新, 并不会影响到和Broker的通信.(Eureka 的本地缓存服务注册信息 )

1.2 Broker

Broker是做消息存储,转发的服务器.
Broker以group分开,每个group只允许一个master,若干个slave.
一个master可以有多个slave,但是一个slave只能有一个master.
只有master才可以进行写入操作, slave不允许.
slave从master中同步数据. 同步策略取决于master的配置, 可以采用同步双写,异步复制两种.
客户端消费可以从master和slave中消费. 在默认的情况下,消费者都从master消费, 在master挂掉之后, 客户端由于从Name Server中感知到Broker挂机,就会从slave消费. (尽量从master消费, 这样消息会比较及时, 不用牵扯到消息复制的延迟问题.)

---

2. RocketMQ集群物理部署结构

RocketMQ的部署结构有一下特点:

• Name Server是一个无状态节点, 可以集群部署, 节点之间没有信息同步.
• Broker部署分为Master和Slave. 一个master对应多个slave,但是一个slave只可以有一个master, 他们之间的对应关系通过制定相同的BrokerName, 不同的BrokerId来定义, BrokerId为0表示master,非0表示Slave, Master也可以部署多个. 每个Broker与Name Server集群中的所有节点建立长连接, 定时注册Topic信息到所有Name Server.
• Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server获取Topic信息,并且向提供服务的Topic服务的Master建立长连接, 并且定时向Master发送心跳.
• Consumer和Name Server集群中的其中一个节点(随机选择)建立长连接, 定期从Name Server取Topic路由信息, 并且向提供Topic服务的Master建立长连接, 且定时发送心跳. Consumer既可以从Master订阅消息,也可以从Slave订阅消息. 规则由Broker决定.

---

3. RocketMQ逻辑部署结构

3.1 Producer Group

用来表示一个发送消息的应用, 一个Producer Group下包含多个Producer实例,可以使多个机器,也可以是一台机器的多个进程, 或者一个进程的多个Producer对象. 一个Producer Group可以发送多个Topic消息, Producer Group的作用如下:

1. 标识一类的Producer
2. 可以通过运维工具查询这个发送消息的应用下有多少个Producer实例.
3. 发送分布式事务消息的时候,如果Producer中途意外宕机,Broker会主动回调Producer Group内的任意一台机器来确认是无状态.

3.2 Consumer Group

用来表示一个消费消息应用,默认为一个Consumer Group下的多个Consumer以均摊的方式消费信息, 如果设置为广播方式的话,这个Consumer Group下的所有Consumer会消费全部的数据.

4. RocketMQ集群部署模式

4.1 单Master模式

也就是只有一个Master节点, 称不上是集群, 一旦这个Master节点宕机, 那么整个服务就不可用, 也就是自己学习的时候搞一搞.

4.2 多Master模式

多个Master节点组成集群, 单个Master节点宕机或者重启对应用没有影响.

• 优点: 所有模式中性能最高.
• 缺点: 单个Master节点宕机期间, 未被消费的消息在节点恢复之前不可用, 消息的实时性就收到影响.
• 注意: 使用同步技术可以保证消息不丢失, 同时Topic相对应的Queue应该分布在急群众的各个节点,而不是某个节点上,否则,该节点的宕机会导致对订阅该topic的应用造成影响.

4.3 多Master多Slave异步复制模式

在多Master的基础上, 每个节点都有至少一个的Slave, Master节点可读可写, 但是Slave节点只读不写, 类似于MySQL的主备模式.

• 优点: 在Master宕机的时候, 消费者可以从Slave读取消息, 消息的实时性不会受到影响, 性能几乎和多Master一样.
• 缺点: 异步复制的同步方式和能导致消息丢失.

4.4 多Master多Slave同步双写模式

同多Master多Slave异步复制模式类似, 区别在于Master和Slave之间的数据同步方式.

• 优点: 同步双写的同步模式能保证数据不丢失.
• 缺点: 发送翻个消息的RT越长, 性能相比异步复制低10%.
• 刷盘策略: 同步刷盘和异步刷盘(节点自身数据是同步还是异步存储)
• 同步方式: 同步双写和异步复制(一组Master和Slave之间的数据同步)

---