RocketMQ回顾整理

为什么要是用MQ

MQ（Message Queue）消息队列是一种“先进先出”的数据结构。

其应用场景主要包含以下3个方面：

1.应用解耦

系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存 系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都 会造成下单操作异常，影响用户使用体验。

使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能 来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常 完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物 流系统发生过几分钟故障。

 2.流量削峰

 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大 量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。

 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响 用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕， 这样总不能下单体验要好。 处于经济考量目的：业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对 流量高峰配置高性能的服务器显然不划算，这时可以使用消息队列对峰值流量削峰

数据分发

通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用 数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可

MQ的优缺点

优点：解耦、削峰、数据的分发

缺点：

系统可用性降低

系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响。如何保 证MQ的高可用？

系统复杂度提高

MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异 步调用。如何保证消息没有被重复消费？如何处理消息丢失情况？如何保证消息传递的顺序 性？

一致性问题

A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功， D系统处理失败。如何保证消息数据处理的一致性？

集群的搭建

角色介绍

Producer：消息生产者，负责生产消息。Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败并且低延迟。

Consumer：消息消费者，负责消费消息。一个消息消费者会从 Broker 服务器中获取到消 息，并对消息进行相关业务处理。

Broker：充当着消息中转角色，负责存储消息、转发消息。

NameServer：是一个 Broker 与 Topic 路由的注册中心，支持 Broker 的动态注册与发现。

Topic：表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是 RocketMQ 进行消息订阅的基本单位。

Message：消息是指，消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条 消息必须属于一个主题。

Queue：存储消息的物理实体。一个Topic中可以包含多个Queue，每个Queue中存放的就是 该Topic的消息。一个Topic的Queue也被称为一个Topic中消息的分区（Partition）。

NameServer 是一个几乎无状态节点，节点之间无任何信息同步，可集群部署。

Broker 部署相对复杂，Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave，但一 个 Slave 只能对应一个 Master。Master 与 Slave 的对应关系是通过指定相同的 BrokerName 和 不同的 BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave。Master 也可以部署多 个。每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 路由信息到 所有的 NameServer 中。

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

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

集群模式

单Master模式

这种方式风险较大，一旦 Broker 重启或者宕机时，会导致整个服务不可用。不建议线上环境使 用,可以用于本地测试。

多Master模式

一个集群无 Slave，全是 Master。例如 2 个 Master 或者 3 个 Master。同一 Topic 中各个 Queue 会 平均分布在各个 Master 节点上。这种模式的优缺点如下：

优点：配置简单，单个 Master 宕机或重启维护对应用无影响，在磁盘配置为 RAID10 时，即 使机器宕机不可恢复情况下，由于 RAID10 磁盘非常可靠，消息也不会丢（异步刷盘丢失少 量消息，同步刷盘一条不丢），性能最高。

缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时 性会受到影响。

以上优点的前提是，这些 Master 都配置了 RAID 磁盘阵列。如果没有配置，一旦出现某 Master 宕机，则会发生大量消息丢失的情况。

多Master多Slave模式（异步）

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

优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，即使 Master 宕机 后，消费者仍然可以从 Slave 消费，而且此过程对应用透明，不需要人工干预，性能同多 Master 模式几乎一样

缺点：Master 宕机，磁盘损坏情况下会丢失少量消息。

---

Slave从Master同步的延迟越短，其可能丢失的消息就越少 对于Master的RAID磁盘阵列，若使用的也是异步复制策略，同样也存在延迟问题，同样 也可能会丢失消息。但RAID阵列的秘诀是微秒级的（因为是由硬盘支持的），所以其 丢失的数据量会更少。

---

多Master多Slave模式（同步）

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

优点：数据与服务都无单点故障，Master 宕机情况下，消息无延迟，服务可用性与数据可用 性都非常高。

缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的 RT 会略高，且目前 版本在主节点宕机后，备机不能自动切换为主机。

---

双主双从

总体架构

消息高可用才用2m-2s (同步双写) 方式搭建

 工作流程

1）首先启动 NameServer，起来后监听端口，等待 Broker、Producer、Consumer 连上来，相当于 一个路由控制中心。

2）Broker 启动，它会跟所有的 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系。

3）收发消息前，先创建 Topic，创建 Topic 时需要指定该 Topic 要存储在哪些Broker上，也可以在 发送消息时自动创建Topic。

4）Producer 发送消息，启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic 存在哪些 Broker 上，轮询从队列列表中选择一个队列，然 后与队列所在的 Broker 建立长连接从而向 Broker 发消息。

5）Consumer 跟 Producer 类似，跟其中一台 NameServer 建立长连接，获取当前订阅 Topic 存在 哪些 Broker 上，然后直接跟Broker 建立连接通道，开始消费消息。

---

消息模型

消息模型：消息模型包括producer,consumer,broker三部分。producer生产消息，consumer消费消息，broker存储消息，broker可以是集群部署，其中topic位于broker中