Cover_sky的博客

RocketMQ在存储延迟消息时，将其保存在一个系统的Topic中，在创建ConsumeQueue时，tagCode字段中保存着延迟消息需要被投递的时间，通过这个存储实现的思路，我们可以总结出延迟消息的投递过程:通过定时服务定时扫描ConsumeQueue,满足投递时间条件的消息再通过CommitLog将消息重新投递到原始的Topic中，消费者就可以接收消息了。

什么是延迟消息呢?延迟消息也叫定时消息，一般地，生产者在发送消息后，消费者希望在指定的一段时间后再消费。常规做法是，把信息存储在数据库中，使用定时任务扫描，符合条件的数据再发送给消费者。典型的业务场景春节买票30分钟内完成订单支付。RocketMQ延迟消息是通过ScheduleMessageService类实现的。

当生产者本地事务处理完成并且Broker回查事务消息后，不管执行Commit还是Rollback,都会根据用户本地事务的执行结果发送一个End_transaction的RPC请求给Broker，Broker端处理该请求的类是EndTransactionProcessor。

如果用户由于某种原因，在第二阶段中没有将endTransaction消息发送给Broker,Broker的Half消息又将如何处理。RocketMQ在设计时已经考虑到这个问题，通过"回查机制"处理第二阶段既未发送Commit也没有发送Rollback的消息。

在Broker中，事务消息的初始化是通过BrokerController.initialTransaction()方法执行的。3个核心的初始化变量。

事务消息机制。事务消息的发送和处理总结为四个过程:1.生产者发送事务消息和执行本地事务2.Broker存储事务消息3.Broker回查事务消息4.Broker提交或回滚事务消息。

Broker关机恢复是指恢复CommitLog、Consume Queue、Index File等数据文件。Broker关机分为正常调用命令关机和异常被迫进程终止关机两种情况。恢复过程的设计目标是使正常停止的进程实现零数据丢失，异常停止的进程实现最少量的数据丢失，与关机恢复相关的主要文件有两个:abort和checkpoint.

配置数据包含4种类型:Topic配置、消费者位点、延迟位点、订阅关系配置。每种配置数据由一个继承自ConfigManager的类来管理，继承关系如图。Slave如何从Master同步这些配置呢?我们先来看一下初始化服务的步骤。

Broker有两种角色Master和Slave.Master主要用于处理生产者、消费者的请求和存储数据。Slave从Master同步所有数据到本地，具体作用体现在两个方面。第一，Broker服务高可用。一般生产环境会部署两个主Broker节点和两个从Broker节点(也叫2m2s),一个Master宕机后，另一个Master可以接管工作；如果两个Master都宕机，消费者可以通过连接Slave继续消费。这样可以保证服务的高可用第二，提高服务性能。

RocketMQ中主要保存了CommitLog、ConsumeQueue、IndexFile三种数据文件。由于内存和磁盘都是有限的资源，Broker不可能永久地保存所有数据，所以一些超过保存期限的数据会被定期删除。RocketMQ通过设置数据过期时间来删除额外的数据文件，具体的实现逻辑是通过DefaultMessageStore.start()方法中的this.addScheduleTask();来实现的。

RocketMQ支持Pull和Push两种消费模式，Push模式是基于Pull模式的，两种模式都是通过拉取消息进行消费和提交位点的。这里我们主要讲Broker在处理客户端拉取消息请求时是怎么查询消息的。

ConsumeQueue和IndexFile两个索引都是由ReputMessageService类创建的RequestMessageService类图ReputMessageService服务启动后的执行过程。CommitLogDispatcherBuildConsumeQueue索引处理器用于构建ConsumeQueue，CommitLogDispatcherBuildIndex用于构建IndexFile。

主要用于消费拉取消息、更新消费位点等所用的索引。源代码参考org.apache.rocketmq.store.ConsumerQueue.该文件内保存了消息的物理位点、消息体大小、消息Tag的Hash值。

在RocketMQ中,有两处地方使用了"读写分离"机制Broker Master-Slave读写分离:写消息到Master Broker,从Slave Broker读取消息。Broker配置为Slave Broker读取消息。Broker配置为slaveReadEnable=True(默认False)，消息占用内存百分比配置为accessMessageInMemoryMaxRatio=40(默认40)

主要负责将消息存储到PageCache或者DM中，存储成功后通过调用handleDiskFlush()/submitFlushRequest()方法将同步刷盘请求"发送给"GroupCommitService服务，并在该刷盘请求上执行锁等待通过GroupCommitService类实现的同步刷盘服务正常同步刷盘线程会间隔10ms执行一次CommitLog.GroupService.doCommit()方法，该方法循环每一个同步刷盘请求，如果刷盘成功，那么唤醒等待刷盘请求锁的存储消息线程，并告知刷盘

RocketMQ的存储涉及中，很大一部分是基于Kafka的涉及进行优化的。

RocketMQ在存储涉及中通过内存映射、顺序写文件等方式实现了高吞吐。RocketMQ的基本数据结构:CommitLog:RocketMQ对存储消息的物理文件的抽象实现，也就是对物理CommitLog文件的具体实现。MappedFile:CommitLog文件在内存中的映射文件，映射文件同时具有内存的写入速度和与磁盘一样可靠的持久化方式.

RocketMQ首先将消息数据写入操作系统PageCache，然后定时将数据刷入磁盘。接下来主要分析RocketMQ是如何接收发送消息请求并将消息写入PageCache的，整个过程如图Commit目录下有多个CommitLog文件，其实CommitLog只有一个文件，为了方便保存和读写，被切分为多个子文件，所有的子文件通过其保存的第一个和最后一个消息的物理位点进行连接。Broker按照时间和物理的offset顺序写CommitLog文件，每次写的时候需要加锁。

Broker启动流程BrokerStartup.java类主要负责为真正的启动过程做准备，解析脚本传过来的参数，初始化Broker配置，创建BrokerController实例等工作。BrokerController.java类是Broker的掌控者，它管理和控制Broker的各个模块，包含通信模块、存储模块、索引模块、定时任务等。在BrokerController全部模块初始化并启动成功后，将在日志中输出info信息"boot success"

Namesrv获取的Topic路由信息来自Broker定时心跳，心跳时Broker将Topic信息和其他信息发送到Namesrv。Namesrv通过RequestCode.REGISTER_BROKER接口将心跳中的Broker信息和Topic信息存储在Namesrv中。

启动命令 nohup ./bin/mqnamesrv -c ./conf/namesrv.conf > dev/null 2>&1 &通过脚本配置启动基本参数，比如配置文件路径、JVM参数，调用NamesrvStartup.main()方法，解析命令行的参数，将处理好的参数转化为Java实例，传递给NamesrvController实例。

Namesrv中保存的数据被称为Topic路由信息，Topic路由决定了Topic消息发送到哪些Broker,消费者从哪些Broker消费消息，那么路由信息都包含哪些数据呢?路由数据结构的实现代码都在RouteInfoManager类中。

调整任意一个实例的订阅关系和另一个保持一致。

RocketMQ设计了消息过滤，来解决大量无意义流量的传输:即对于客户端不需要的消息，Broker就不会传输给客户端，以免浪费宽带，RocketMQ4.2.0支持Tag过滤、SQL92过滤、Filter Server过滤。

ConsumeMessageService是一个通用的消费服务接口，它包含两个实现类org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService和org.apache.rocketmq.client.impl.consumer.ConsumeMessageOrderlyService，这两个实现类分别用于并发消费和顺序消费。

在Rebalance时，org.apache.rocketmq.client.impl.consumer.RebalanceImpl#updateProcessQueueTableInRebalance方法在运行时设置ProcessQueue.setDropped(true)的逻辑，，设置成功后，在执行拉取消息时，将不再拉取dropped为true的ProcessQueue。顺序消费时，如果当前拉取的队列在Broker没有被锁定，说明已经由拉取正在执行，当前拉取请求晚点执行，如果不是第一次拉取，

消费者启动时会同时启动位点管理器，RocketMQ设计了远程位点管理和本地位点管理两种位点管理方式.集群消费时，位点由客户端提交给Broker保存.广播消费时，位点保存在消费者本地磁盘上。

客户端是通过Rebalance服务做到高可靠的。当发生Broker掉线、消费者实例掉线、Topic扩容等各种突发情况时，消费者组中的消费者实例是怎么重平衡的，以支持全部队列的正常消费的?

RocketMQ客户端中有两个独立的消费者实现类分别为DefaultMQPullConsumer和DefaultMQPushConsumer，

首先RocketMQ客户端接收业务层消息，然后通过DefaultMQProducerImpl发送一个RPC请求给Broker,再由Broker处理请求并保存消息,以DefualtMQProducerImpl.send()接口为例，消息发送流程具体分为3步。

生产者启动的流程比消费者启动的流程更加简单一般用户使用DefaultMQProducer的，构造函数构造一个生产者实例，并设置各种参数，比如，Namesrv地址、生产者组名等，调用start()方法启动生产者实例，start()方法调用了生产者默认实现类的start()方法启动，这里我们主要分析start()方法内部是怎么实现的。

如果Broker以一个集群的方式部署，会有一个master节点和多个Slave节点，消息需要从master复制到slave上，而消息复制的方式分为同步复制和异步复制。

在RocketMQ的管理控制台创建Topic时，可以看到要单独设置读队列和写队列。通常在运行时，都需要设置读队列=写队列。perm字段表示Topic的权限，有三个可选项2：禁写禁订阅4: 可订阅6: 可写可订阅这其中，写队列会真实的创建对应的存储文件，负责消息写入。而读队列会记录Consumer的Offset，负责消息读取，这其实是一种读写分离的思想。RocketMQ在设置MessageQueue的路由策略时，就可以通过指向不同的队列来实现读写分离。

1.生产者使用事务消息机制2.Broker配置同步刷盘+Dledger主从架构3.消费者不要使用异步消费4.整个MQ挂了之后准备降级方案这套方案在各个环节都大量地降低了系统地处理性能以及吞吐量。在很多场景下，这套方案带来的性能损失的代价可能远大于部分消息丢失的代价。所以在使用这套方案时，要根据实际的业务情况来考虑，例如，如果针对所有服务器都在同一个机房的场景，完全可以把Broker配置成异步刷盘来提升吞吐量。

了解之前，首先要熟悉RocketMQ中的组件架构设计。

RocketMQ是阿里巴巴于2012年开源的分布式消息中间件，后来捐赠给Apache软件基金会，并于2017年9月25日称为Apache的顶级项目.作为经历多过多次阿里巴巴双11这种超级工程的洗礼并有稳定出色表现得国产中间件，以其高性能、低延迟和高可靠等特性近年来被越来越多的国内企业所使用。

3.系统A根据本地事务执行结果再向消息中间价发送提交消息，以提交二次确认，如果消息中间件得到不到系统A的本地事务执行情况，将会执行系统A实现的本地事务回查接口。1.系统A先向消息中间件发送一条预备消息(Half Message)，消息中间件在保存好消息之后向系统A发送确认消息。所谓事务消息就是基于消息中间件模拟的两阶段提交(2PC)，属于对消息中间件的一种特殊利用。4.消息中间件收到提交消息后，把预备消息标记为可投递，订阅者最终将接收到该消息。2.系统A执行本地事务。

3.Nacos通用的服务注册和参数配置，虽然Nacos是AP，但是RocketMQ中NameServer做的事情比较少，只需要保管好这些Broker的信息即可，这是一个轻量级框架。4.如果要用分布式，则必然要解决脑裂问题，当出现网络分区，选出两个Master时，则需要再次进行选举。如果客户端发消息请求NameServer发送失败，重发即可，在用Zookeeper，一致性期间，2.ZooKeeper在CAP理论中保证的是CP，站在服务中心的角度来看，AP要比CP好，NamerServer无法访问。

所以在水平扩容消费者上面，相对RocketMQ来说不是那么地直接，在Kafka中需要做进一步考虑,多说一句，在RocketMQ中由于业务场景不同，相比Kafka处理的业务场景要复杂地多，所以RocketMQ需要支持消费者的水平扩容，这样就会出现消息竞争，但是为了水平扩容，RocketMQ需要这样做。我们知道当消息生产者生产的速度快于消费者的消费速度时，会产生大量的消息积压，大多数人的想法是增加消费者的数量来提升消费速度，这个想法在RocketMQ中是可行的，但是在Kafka中不一定可行。

具体实现原理是，kafka每次发送消息会生成PID和Sequence Number，并将这两个属性一起发送给broker，broker会将PID和Sequence Number跟消息绑定一起存起来，下次如果生产者重发相同消息，broker会检查，PID和Sequence Number，如果相同不会再接收。打开文件这些场景下，在Linux系统的默认设置下，这个文件描述符的个数不是很多，通过ulimit -n命令可以查看一般默认是1024，可以将该值调大比如 ulimit -n 65535。