RocketMq

置顶我的搬砖日常

已于 2022-12-18 20:14:50 修改

阅读量1k

点赞数

文章标签： rocketmq java

于 2022-08-05 23:29:36 首次发布

本文链接：https://blog.csdn.net/weixin_44383484/article/details/126173616

版权

mq 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

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

4.4 多Master多Slave模式-同步双写

1官网：

自己搭建的话有一些硬性的要求(4g以上磁盘空间等等)，大体看看官网，升级mq的集群

Quick Start - Apache RocketMQ

2 架构图

3流程：

Broker1(master),Broker1(slave),Broker2(master),Broker2(slave) 全部回向nameServer1，nameServer2去注册自己的信息，

因为 nameServer 是无状态的，每个都是独立的，这就会导致不知道有哪台Broker，所以所有的Broker都会去向所有的 nameServer 去注册。好处就是随意扩展 nameServer 集群。效率会高，因为没有数据同步一说，

每个nameServer 会像所有的 Broker去每隔10秒去检测是否存活。不存活则剔除出去。每个Broker也会每隔30秒往nameServer 上报一次 topic等信息
producer 会向 nameServer集群中任意一台，获取我们topic对应的Broker服务。获取到之后，会连接到对应Broker来发送消息。
Consumer 消费消息的时候，会向Broker(master)发送请求，请求不通，回向从节点发送，保证消息不丢失。

保证高可用，producer 与nameServer和Broker都有长链接，都保持心跳，producer 每隔30秒会向nameServer拉取信息，看topic有没有变更。假如Broker1挂掉，nameServer还没检测呢，producer 还是会往Broker1发送消息，发送失败时会向另一个Broker发送。

Consumer 会从Broker(master) 获取消息，并不会从Broker(slave)获取，什么时候会从从节点获取消息呢？主节点挂掉，或者主节点消息堆积太多，默认超过物理内存的40%后，会建议从从服务器读取。

nameServer：

注册中心作用，

Broker：

消息存储中心，接收来自 Producer 的消息并存储， Consumer 从这里取得消息，它还存储与消息相关的元数据，包括用户组、消费进度偏移量、队列信息等，从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型，Master 既可以写又可以读，Slave 不可以写只可以读。

事务的信息

事务消息 - 消息队列RocketMQ版 - 阿里云

4集群搭建

4.1单Master模式

一旦Broker重启或者宕机时，会导致整个服务不可用。

4.2 多Master模式

全是Master，这种模式的优缺点如下：

优点：配置简单，单个 Master 宕机或重启维护对应用无影响。（宕机后消息不会发到这台Master上了，producer 可以继续发送消息，因为topic可以存在不同的Broker上）。
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

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

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

优点：Master宕机后，消费者仍然可以从Slave消费；
缺点：Master消息还未异步传给Slave就宕机了，Slave会丢失少量消息，导致消费不到。

4.4 多Master多Slave模式-同步双写

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

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

5生产者（Producer）

RocketMQ提供了发送：同步、异步和单向（one-way）,延时消息，的多种模式

同步发送

同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包，一般用于重要通知消息，例如重要通知邮件、营销短信。

异步发送(有回调函数)

异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。

单向发送

单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。

生产者组(分布式架构原因)

生产者组（Producer Group）是一类 Producer 的集合，这类 Producer 通常发送一类消息并且发送逻辑一致，所以将这些 Producer 分组在一起，从部署结构上看生产者通过 Producer Group 的名字来标记自己是一个集群。

生产者高可用保障

Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳，Producer完全无状态，可集群部署。

Producer每隔30s（由ClientConfig的pollNameServerInterval）从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。

Producer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。

消费者（Consumer）

Pull：Pull型消费者主动地从brokers那里拉取信息，只要批量拉取到消息，用户应用程序就会启动消费过程

消费者组

消费者组（Consumer Group）一类 Consumer 的集合名称，这类 Consumer 通常消费同一类消息并且消费逻辑一致，所以将这些 Consumer 分组在一起，消费者组与生产者组类似，都是将相同角色的分组在一起并命名，分组是个很精妙的概念设计，RocketMQ 正是通过这种分组机制，实现了天然的消息负载均衡。

消费消息时通过 Consumer Group 实现了将消息分发到多个消费者服务器实例，比如某个 Topic 有9条消息，其中一个 Consumer Group 有3个实例（3个进程或3台机器），那么每个实例将均摊3条消息，这也意味着我们可以很方便的通过加机器来实现水平扩展。

消费者高可用保障

Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳，Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。

Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。

当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失，但是一旦master恢复，未同步过去的消息会被最终消费掉。