RocketMQ集群流程以及核心概念

一、为什么要集群

  • 单点存在单点故障问题
  • 集群可以分担压力,提高QPS
  • 主从可以保证消息可靠性,比如只有M没S。M磁盘坏了,那未被消费的消息都丢了。而S可以作为备份。

二、单M模式

1、特点

  • 只有一个Master节点,所以单点故障是致命缺点。
  • 优点:配置简单,方便部署。
  • 缺点:单点故障,一旦Broker重启或者直接宕机了,那会导致整个服务不可用。

2、图解

在这里插入图片描述

三、多M模式

1、特点

  • 一个集群无Slave节点,全是Master节点。
  • 优点:配置相对不复杂,单个M宕机或者重启对业务系统无感知,照常提供服务。只是这个broker上如果有消息未被消费的话可能无法继续消费,但是消息不会丢失,持久化到磁盘的。异步刷盘的话会存在少量丢失。
  • 缺点:单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会受到受到影响。

2、图解

在这里插入图片描述

四、多M多S模式

一个集群既有Master节点又有Slave节点。

1、异步复制

  • 每个 Master 配置一个 Slave,有多对Master-Slave, HA,采用异步/同步复制方式,主备有短暂消息延迟,毫秒级。
  • 优点:即使磁盘损坏,消息丢失的非常少,且消息实时性不会受影响,因为Master 宕机后,消费者仍然可以从 Slave消费,此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
  • 缺点: Master 宕机,磁盘损坏情况,会丢失少量消息。

2、同步双写

  • 每个 Master 配置一个 Slave,有多对Master-Slave, HA采用同步双写方式,主备都写成功,向应用返回成功。

  • 优点:数据与服务都无单点, Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高。

  • 缺点:性能比异步复制模式略低,大约低 10%左右,发送单个消息的 RT会略高。目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。

  • 要想真正意义的保证消息不丢失,这个同步双写是必须的 。

3、图解

在这里插入图片描述

五、queue的分布

一个topic的queue可以分布到多个Broker上。比如一个topic有4个queue,他可能分配到broker-a上三个queue,broker-b上1个queue,这个queue的分配是由broker端决定的。但是为了验证猜想我们可以手动从管控台去创建这个topic,成功的话可以验证我们的猜想。

首先我有2M2S的一个集群
在这里插入图片描述

创建topic
在这里插入图片描述
创建topic
在这里插入图片描述
查看status,可以发现为我们在每个broker上都创建了4个queue,也就是一共8个queue了。
在这里插入图片描述
点击【TOPIC CONFIG】更改配置
在这里插入图片描述
再次查看就会发现已经生效了,验证了我们的猜想
在这里插入图片描述
每个queue的消息都是不一样的,也就是比如你发N条消息,他可能一部分在broker-a上一部分在broker-b上,不管他在哪,消息都是不一样的,不要理解成M-S那种复制。他只是负载均衡将queue分配到了不同的broker上。
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_33762302/article/details/114772162
今日推荐