分布式中间件之RocketMq

---

前言

本文主要是列举一下学习RocketMq的过程中比较重要的概念及实现原理。

---

一、有序性

在使用MQ的过程中，大家关心的第一点应该是就是有序性，尤其是在分布式的环境中。RocketMq的有序性可以分为全局有序、局部有序。在分布式的环境下，全局有序的实现为：保证需要有序的Topic有且仅有一个队列；而局部有序则是需要用户在发送消息时，将需要有序的消息发送到同一个队列上来保证有序。

二、Broker和NameServer的关系

RocketMq的整体架构分为Producer、Consumer、Broker、NameServer，大家对Broker和NameServer的关系及作用比较容易混淆。这里我们可以从微服务的角度来看，NameServer可以看作是一个“注册中心”而Broker可以看做是一个“工做节点”。Broker启动之后会主动向NameServer汇报自己的信息，NameServer则捏合🤌各个Broker的数据，捏合后的结果就是整个集群元数据的体现。并支持Producer｜Consumer获取路由信息（也就是Topic存在于哪一个Broker中）。

这里我们可以做一个小实验，准备两台服务器，两台机器分别启动一个Broker和NameServer，机器1的broker注册到本机的NameServer上，机器2的Broker也注册到机器1的NameServer上。

此时我们通过命令或者java客户端去连接NameServer可以发现，如果连接机器1的NameServer可以读取到两个Broker内的数据，但如果连接到机器2的NamerServer上则读取不到数据。

三、消费方式

RocketMq的消费方式与其他同类型的MQ一样，支持广播消息和一对一消息。这里需要注意的是：集群模式的：offset偏移量是有集群来管理的；而广播模式的偏移量是有Consumer自己来管理的。

四、持久化

任何中间件都逃不开的一个问题，就是持久化，RocketMq的持久化是通过一个commitLog文件来进行。所有的数据都会线性的append到这个commitLog文件中。既然是文件那就主要是有两个问题，第一个数据是如何写入文件；第二个consumer是如何读取文件。我们先来说数据是如何写入的，这里要结合相关系统IO的知识；首先我们需要根据配置判断是是否开启了堆外内存，如果开启了则封装后的数据会首先写入堆外内存，然后会先执行commit操作将数据提交到mappedFile中；如果没有开启堆外内存则会直接写入到MappedFile。
数据提交到内存中以后，rocketMq会有特定的线程，将数据刷写道磁盘中。

这里提一下SWAP，SWAP在内存不足时时用硬盘的一部分空间作为缓存，如果开启了，可能会导致数据还没有写入磁盘时被放到缓冲区中，当你准备写入磁盘则需要从缓冲区再拿到内存中，可能会降低效率。接下来讲讲如何读取：

当文件数据存储到对应的commitLog后，broker也会consumerQueue来存储消息在commit的偏移量，以及Index。consumer消费消息时，会先从自己对应的consumerQueue中读取偏移量，然后去CommitLog中查找对应的消息。

五、MQ如何进行topic对应的队列缩小

在使用过程中，一开始我们存在3个producer、3个consumer，随着需求变化消息量减少，如何安全平稳的进行缩小producer、consumer从而释放资源。

六、事务消息

RocketMQ采用了两段式提交来保证了最终一致性，Producer首先会向Broker发送半消息，此时Consumer是无法获取到该消息的，半消息发送成功，用户可以开始执行本地的事务处理，如果事务处理失败，则发送回滚消息、如果本地处理成功则发送提交消息。如果服务器此时当机，broker触发check机制，主动调用用户接口，来判断是否本地事务处理成功，如果成功，则提交消息consumer可以消费到，反之则回滚消息。

七、消费方式

RocketMQ的消费方式分为推和拉两种方式，但其实本质上都是拉的方式，推的方式只是由consumer主动定时去broker拉取消息。但是如果拉去到消息后逻辑处理失败会怎办？

Consumer拉去到消息以后如果本地逻辑处理失败，Consumer会主动把消息发送回道broker中，broker利用延时队列，重新将消息放回对应topic，由consumer继续消费，冲过超过一定次数后，消息最终会放到死信队列。

---

总结

以上就是在我学习RocketMQ的过程中遇到的一些问题，已经个人认为比较重要的点。如果有什么不对的地方，希望大家一起评论探讨一下。