RocketMQ高级-集群工作流程，消息的存取方式、存储结构，刷盘机制，高可用，主从复制，负载均衡，消息重试，死信队列，消息幂等

1 集群

• 多个broker提供服务

• 多个master多个slave

  ​ master到slave消息同步方式为同步（较异步方式性能略低，消息无延迟）

  ​ master到slave消息同步方式为异步（较同步方式性能略高，数据略有延迟）

1.1 集群特征

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配置决定。

总结:

1) nameserver有多个
2) master 多个,每个master 都有多个 slave
3) master 的 brokerid =0 , slave 的  brokerid 非0 
4) 多个 master 和多个slave  如果 brokername 相同则 为一组
5) master 和slave 会将自己注册到每一台 nameserver 上 

1.2 集群的工作流程

步骤1：NameServer启动，开启监听，等待broker、producer与consumer连接
步骤2：broker启动，根据配置信息，连接所有的NameServer，并保持长连接
步骤2补充：如果broker中有现存数据， NameServer将保存topic与broker关系
步骤3：producer发信息，连接某个NameServer，并建立长连接
步骤4：producer发消息
    步骤4.1若果topic存在，由NameServer直接分配
    步骤4.2如果topic不存在，由NameServer创建topic与broker关系，并分配
步骤5：producer在broker的topic选择一个消息队列（从列表中选择）
步骤6：producer与broker建立长连接，用于发送消息
步骤7：producer发送消息

comsumer工作流程同producer

1.3 搭建

具体操作查看RocketMQ集群配置：https://blog.csdn.net/weixin_45195665/article/details/110351367

2 高级特性介绍

2.1 消息的存储(消息存在哪儿?)

ActiveMQ 使用了数据库的消息存储,
缺点：数据库瓶颈将成为MQ瓶颈

RocketMQ/Kafka/RabbitMQ
不用数据库,直接用文件存储(如下)

2.2 MQ 高效的消息存储与读写方式

1，通过占用固定的磁盘空间来保证顺序写

SSD(Solid state Disk) 固态硬盘

• ​ 随机写：100K/S
• ​ 顺序写：600M/S

RocketMQ采用顺序写的方法往硬盘写入数据：它预先占用一定的磁盘空间，然后按顺序写入相关的数据，以保证写入的速度和效率。

机械盘和固态盘的区别：

机械盘：数据是存储的扇区的，读写是依靠磁头的摆动寻址的。顺序读写主要时间花费在了传输时间，随机读写需要多次寻道和旋转延迟。

固态盘：是由控制单元和固态存储单元（DRAM或FLASH芯片）组成，存储单元负责存储数据，控制单元负责读取、写入数据。

由于固态硬盘没有普通硬盘的机械结构，也不存在机械硬盘的寻道问题。

顺序读写和随机读写对比：

随机读写是相对顺序读写而言的，所谓随机读写，是指可以在任何时候将存取文件的指针指向文件内容的任何位置。一般情况下SAS机械硬盘主要是看顺序读写性能，SSD固态盘主要看随机读写性能。

文件的操作方式：

顺序读写：文件指针只能从头移动到尾。

随机读写：文件指针可以随意移动，根据需要。

总结：相对而言，如果是写入数据，顺序写入性能高一些，如果是读取数据，随机读取会比较快一些。
假设有1到1000笔的数据。
情况1：现在要读出第1000笔，顺序读写的方式是从第1笔开始读，一直找到第1000笔；随机读写是通过运算，很快的找到第1000笔。
情况2：要找出含“abc”的数据，顺序读写还是从第1笔开始读，一直找到第1000笔；随机读写是通过运算，很快的找到“abc”的数据。

关于磁盘碎片：目前WINDOWS和LINUX都会自动帮我们整理，不用担心。

2，通过“零拷贝”技术实现数据传输由传统的4次复制简化为3次复制，去掉了中间用户态的数据转换过程

常规数据读写的基本流程：

进程发起read请求之后，内核接收到read请求之后，会先检查内核空间中是否已经存在进程所需要的数据，如果已经存在，则直接把数据copy给进程的缓冲区；如果没有内核随即向磁盘控制器发出命令，要求从磁盘读取数据，磁盘控制器把数据直接写入内核read缓冲区，这一步通过DMA完成；接下来就是内核将数据copy到进程的缓冲区；
如果进程发起write请求，同样需要把用户缓冲区里面的数据copy到内核的socket缓冲区里面，然后再通过DMA把数据copy到网卡中，发送出去；
你可能觉得这样挺浪费空间的，每次都需要把内核空间的数据拷贝到用户空间中，所以零拷贝的出现就是为了解决这种问题的；
关于零拷贝提供了两种方式分别是：mmap+write方式，sendfile方式；

使用虚拟内存来减少copy的次数：

使用虚拟的地址取代物理地址，这样做的好处是：
1）一个以上的虚拟地址可以指向同一个物理内存地址，
2）虚拟内存空间可大于实际可用的物理地址；
利用第一条特性可以把内核空间地址和用户空间的虚拟地址映射到同一个物理地址，这样DMA就可以填充对内核和用户空间进程同时可见的缓冲区了，大致如上图所示。

零拷贝如果简单用java里面对象的概念来理解的话，其实就是使用的都是对象的引用，每个引用对象的地方对其改变就都能改变此对象，永远只存在一份对象。

小结：

1) 通过启动时初始化化文件大小来保证 占用固定的磁盘空间,保证磁盘读写速度
2) 零拷贝”技术
	数据传输由传统的4次复制简化成3次复制(如下图)，减少1次复制过程
	Java语言中使用MappedByteBuffer类实现了该技术
	要求：预留存储空间，用于保存数据（1G存储空间起步）

2.3 消息存储结构

消息数据存储区域：存储消息队列中的消息    commitlog目录
    topic
    queueId
    message
消费逻辑队列：专门记录每个队列的消费情况，每个消息队列对应有一个消费逻辑队列记录其消费情况，也就是每个消息在消息队列中的位置   consumerQueue目录
    minOffset：最小索引
    maxOffset：最大索引
    consumerOffset：当前消费者消费到什么位置
索引：每个消费队列对应有一个索引，用来快速查找消息队列中的消息数据   index目录
    key索引
    创建时间索引
    ……

2.4 刷盘机制

持久化：数据在临时态和持久态之间相互转换的过程。

最终将内存数据存到磁盘文件的过程称为刷盘: 分为同步刷盘和异步刷盘。

2.4.1 同步刷盘

1)生产者发送消息到MQ，MQ接到消息数据
2)MQ挂起生产者发送消息的线程
3)MQ将消息数据写入内存
4)内存数据写入硬盘
5)磁盘存储后返回SUCCESS
6)MQ恢复挂起的生产者线程
7)发送ACK到生产者

2.4.2 异步刷盘

1)生产者发送消息到MQ，MQ接到消息数据
2)MQ将消息数据写入内存
3)发送ACK到生产者
--等消息量多了--
4)内存数据写入硬盘

2.4.3 同步刷盘/ 异步刷盘 优缺点对比

同步刷盘：安全性高，效率低，速度慢（适用于对数据安全要求较高的业务）
异步刷盘：安全性低，效率高，速度快（适用于对数据处理速度要求较高的业务）

2.4.4 配置方式

#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH

小结:

同步刷盘和异步刷盘的区别如下:

同步刷盘:当数据写如到内存中之后立刻刷盘(同步)，在保证刷盘成功的前提下响应client。
异步刷盘:数据写入内存后，直接响应client。异步将内存中的数据持久化到磁盘上。
同步刷盘和异步输盘的优劣:

同步刷盘保证了数据的可靠性,保证数据不会丢失。
同步刷盘效率较低,因为client获取响应需要等待刷盘时间，为了提升效率，通常采用批量输盘的方式，每次刷盘将会flush内存中的所有数据。(若底层的存储为mmap，则每次刷盘将刷新所有的dirty页)
异步刷盘不能保证数据的可靠性.
异步刷盘可以提高系统的吞吐量.
常见的异步刷盘方式有两种,分别是定时刷盘和触发式刷盘。定时刷盘可设置为如每1s刷新一次内存.触发刷盘为当内存中数据到达一定的值，会触发异步刷盘程序进行刷盘。

3 高可用性

nameserver

nameserver通过无状态+全服务器注册 来保证即使一个宕机了也能提供所有的服务

消息服务器

主从架构（2M-2S） ,即使又一台服务器宕机, 服务依旧可以正常提供
注意: master 一旦宕机,slave 只提供消费服务,不能写入新的消息(slave 不会升级为master)

消息生产(开发人员写代码时保障)

生产者将相同的topic绑定到多个group组，保障master挂掉后，其他master仍可正常进行消息接收

消息消费

RocketMQ自身会根据master的压力确认是否由master承担消息读取的功能，当master繁忙时候，自动切换由slave承担数据读取的工作

4 主从数据复制

4.1 同步复制

master接到消息后，先复制到slave，然后反馈给生产者写操作成功
优点：数据安全，不丢数据，出现故障容易恢复
缺点：影响数据吞吐量，整体性能低

4.2 异步复制

master接到消息后，立即返回给生产者写操作成功，当消息达到一定量后再异步复制到slave
优点：数据吞吐量大，操作延迟低，性能高
缺点：数据不安全，会出现数据丢失的现象，一旦master出现故障，从上次数据同步到故障时间的数据将丢失

4.3 配置(配置在启动时 -c 指定的配置文件中 broker.conf)

#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER

读写分离：

​ 存储数据超过Broker所设置内存量的40%时，Broker的master自动将一部分读的功能交给Slave， master 此时主要负责写数据。

5 负载均衡

• Producer负载均衡

  内部实现了不同broker集群中对同一topic对应消息队列的负载均衡：无论此topic是否在同一个broker服务器上，均按消息队列进行负载均衡存储。

• Consumer负载均衡

  平均分配 ：容易造成一台broker挂了，消费者空闲

基本规则：消费者的数据不能超过所监听的Topic中的消息队列的数量,否则会造成多出来的消费者闲置。

​ (一个消费者可以监听消费多个消息队列，但是一个队列只能被一个消费者监听消费。)

循环平均分配：解决平均分配造成的问题

6 消息重试

当消息消费后未正常返回消费成功的信息将启动消息重试机制

6.1 顺序消息重试

当消费者消费消息失败后，RocketMQ会自动进行消息重试（每次间隔时间为 1 秒）
注意：应用会出现消息消费被阻塞的情况，因此，要对顺序消息的消费情况进行监控，避免阻塞现象的发生

6.2 无序消息重试

无序消息包括普通消息、定时消息、延时消息、事务消息
无序消息重试仅适用于负载均衡（集群）模型下的消息消费，不适用于广播模式下的消息消费
为保障无序消息的消费，MQ设定了合理的消息重试间隔时长
重试16次

7 死信队列

7.1 概念

当消息消费重试到达了指定次数（默认16次）后，MQ将无法被正常消费的消息称为死信消息（Dead-Letter Message）
死信消息不会被直接抛弃，而是保存到了一个全新的队列中，该队列称为死信队列（Dead-Letter Queue）

7.2 死信队列特征

- 归属某一个组（Gourp Id），而不归属Topic，也不归属消费者
- 一个死信队列中可以包含同一个组下的多个Topic中的死信消息
- 死信队列不会进行默认初始化，当第一个死信出现后，此队列首次初始化

7.3 死信队列中消息特征

- 不会被再次重复消费
- 死信队列中的消息有效期为3天，达到时限后将被清除

7.4 死信处理

在监控平台中，通过查找死信，获取死信的messageId，然后通过id对死信进行精准消费

一条消息进入死信队列，意味着某些因素导致消费者无法正常消费该消息。因此，通常需要我们对其进行特殊处理。排查可疑因素并解决问题后，可以在消息队列 RocketMQ 控制台重新发送该消息，让消费者重新消费一次。

8 消息重复消费 与 消息幂等

8.1 消息重复消费原因

1 生产者发送了重复的消息
    网络闪断
    生产者宕机
2 消息服务器投递了重复的消息
	网络闪断
3 动态的负载均衡过程
    网络闪断/抖动
    broker重启
    订阅方应用重启（消费者）
    客户端扩容
    客户端缩容

8.2 消息幂等

对同一条消息，无论消费多少次，结果保持一致，称为消息幂等性

8.2.1 解决方案

- 使用业务id作为消息的key
- 在消费消息时，客户端对key做判定，未使用过放行，使用过抛弃

注意：messageId由RocketMQ产生，messageId并不具有唯一性，不能作用幂等判定条件

9 总结

1，集群

2，消息的存储: 数据最终存在硬盘的文件中.

​ 顺序写和零拷贝。

3，commitlog: 消息内容

​ consumequeue: 消费队列的消费情况

​ index: 消息的索引

4, 将rocketmq内存中的消息写入硬盘的过程。同步和异步刷盘.

5, 高可用：为了避免宕机 多弄几个服务器。主从复制：主和从的rocketmq要进行数据同步，两种：同步和异步

6, 负载均衡：为了提高系统的并发能力。

7，消息重试：顺序消息和非顺序消息均会进行重试操作。

8，消息幂等性：为了解决重复消费消息的问题。

​