RocketMQ如何消息队列保证高可用（集群）

总结：NameServer、Broker、双主双从、主从复制、数据刷盘、心跳

1. 以RocketMQ为例

1. 几个概念

1. Topic消息类型（大类）

是相当于一种消息类型，通过topic可以找到对应的broker机子

2. Queue队列（明细类）

是属于某个Topic下的更细分的一种单元，一个broker机子有多个queue

3. 消费者组

消费者和消费者组属于个体与群体的关系

原文链接：rocketMQ中，消费者、消费者组、Topic、队列的关系

2. RocketMQ消息的存储结构（ConsumeQueue + CommitLog）

1. ConsumeQueue 逻辑队列（类似索引，指向真的文件CommitLog）

消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个 Topic下的每个 Message Queue都有一个对应的 ConsumeQueue文件

白话文：逻辑队列这么难记，不如叫索引队列吧！

2. CommitLog （提交日志？这名字也太怪了）刷盘后存在磁盘上的文件

消息真正的物理存储文件，每台 Broker上的 CommitLog被本机器所有 ConsumeQueue 共享。

白话文：刷盘后存在磁盘上的文件，真实的文件

3. 实现高可用的思路（多个Broker）

在实际生产环境中，一般需要服务达到高可用、无单节点故障的要求。在 rocketMq 中
就需要分布式部署。

白话文：分布式部署，就是所有节点不能部署到同一台机子上，不然这台机子挂了，全部节点都挂了，失去了集群的意义

RocketMQ的核心就是Broker的消息存储，而高可用的关键也在于Broker。

4. NameServer（类似于注册中心，管理Broker的）

因为NameServer是无状态的，如果要使用集群部署，只要有一台NameServer可用，那么集群就整体可用。

无状态：指的是节点平等，没有主从等一些关系

白话文：NameServer直接部署多个节点，自成集群（自动化形成集群。。很高级）

5. Broker（存储消息的服务）

一个很重要的消息存储模块

1. 作用

1. 接收Producer发过来的消息

2. 消息的持久化存储

Broker会把CommitLog文件通过刷盘的方式持久化到磁盘上，Broker中就留了一个类似索引的东西，叫做ConsumeQueue

3. 处理Consumer的消费消息请求

4. 消息的 HA 机制（高可用机制、同步机制）

消息到达主服务器后需要将消息同步到从服务器，如果主服务器 Broker 宕机后，消费者可以从从服务器拉取消息

2. Broker集群数量配置（推荐使用双主双从）

就是Broker的主从机子的数量，我自己猜有下面几种情况：

1. 一主多从

2. 双主双从（推荐）

为什么推荐使用双主双从？因为高可用

3. 多主多从

3. 主从复制模式配置（消息从主机到从机的过程）

把消息主节点复制到从节点的过程

注意：主从复制策略只在主节点配置就可以，相关配置的命名：主节点MASTER、从节点SLAVE

主从复制模式可以分为同步或者异步：

1. 同步双写（又叫同步复制）

同步双写保证消息不会丢失，如果5s内未完成消息复制，则给生产者Producer返回结果：数据同步到Slave服务器超时 SendStatus.FLUSH_SLAVE_TIMEOUT

1. 优点（消息不丢失）

保证消息不会丢失

2. 相关配置

brokerRole = SYNC_MASTER

2. 异步双写（又叫异步复制，是默认方式）

1. 优点

异步复制性能高

2. 相关配置

brokerRole = ASYNC_MASTER

4. 数据刷盘模式配置（消息从内存到磁盘的过程）

指的是消息（包括主从）被写入内存的pagecache再存到磁盘的过程

白话文：把消息从内存到磁盘的过程（持久化到磁盘，防止消息丢失？？这里的内存是包括主节点和从节点吗？包括的）

1. 同步刷盘

如果5s内未完成刷盘，则给生产者Producer返回结果：刷盘超时 SendStatus.FLUSH_SLAVE_TIMEOUT

1. 优点（保证消息持久化）

偏向消息高可靠，保证消息持久化

2. 相关配置

flushDiskType = SYNC_FLUSH

2. 异步刷盘（默认方式）

偏向性能，异步刷盘性能比较高

flushDiskType = ASYNC_FLUSH

4. 主从复制和刷盘模式的选择（两两组合四种情况）

• 异步复制，异步刷盘：如果偏向性能的话
• 同步双写，同步刷盘：如果偏向消息高可靠，不在乎性能
• 同步双写，异步刷盘：如果需求居中
• 异步双写，同步刷盘：啥玩意？？忽略（都不给你加粗）

如果断电等瞬时故障导致主从同时宕机可能会丢失几条消息。正常情况异步复制一台机器发生故障不会丢失数据。

5. 双主双从模式下的故障分析情况

原文链接：RocketMq高可用部署/消息高可靠性方案以及故障模拟

1. 题外话：问，双主之间是如何同步的？？

TODO

6. NameServer和Broker的关系（心跳）

每个Broker会和所有的NameServer保持长连接（通过心跳的方式）

1. 如何维持心跳

1. NameServer怎么做

nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。

白话文：NameServer每10s检测一次broker，如果broker超过2min没发心跳，则断开这个broker，并更新topic与队列queue的对应关系，但不会通知生产者和消费者

2. Broker怎么做

Broker每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。

白话文：Broker每30s给所以NameServer发送心跳（包含topic配置信息）