qq_27586963的博客

事务消息和延时消息在隐藏原始消息用的是同一套逻辑。通过新增一个topic，达到对消费者隐藏的目的。当条件满足时，把新增的隐藏topic还原为原有topic，此时消费者可以消费消息。事务消息业务方要自定义监听器，executeLocalTransaction方法写本地业务，checkLocalTransaction方法写回查方法。通过者两个方法实现事务一致性的检查。事务消息不能是延迟消息和批量消息，是完全独立的一个消息RocketMQ源码学习十一：延迟消息。

延时消息的发送在生产段指定延迟级别，延时消息有18个延时级别。在broker存储延时消息的时候，所有延迟消息都塞到topic名称为SCHEDULE_TOPIC_XXXX的topic中，并且同一个延迟级别用的是一个queueId。分为18个队列，这些队列和延迟级别一一对应。原消息的topic和queueId也会存在消息体中。当延时消息时间到了以后，会把延时消息还原为原来的消息结构。

顺序消费分为两个部分，一是消息发送方：会根据用户指定的逻辑发送到指定的消息队列，这样就可以保证统一类型的消息在同一个消息队列中；二是消费方：在消费者消费消息的时候会对队列进行加锁，只有拿到锁的消费者才能消费消息。消息的消费逻辑：首先在平衡类rebalanceService会监听消费者组注册表，如果发生变化会把消费任务塞到PullMessageService类的消费任务队列表pullRequestQueue中；

消息订阅会把当前需要拉取的topic注册到订阅关系中，同时会把消费者消息监听器设置到客户端系统中。客户端实例MQClientInstance在启动的时候会启动一个循环线程，此线程会不断的拉取消费者组注册表信息，当订阅关系发生改变的时候就会触发消费者消息监听器。监听器中会启动消息拉取任务PullTaskImpl方法，从broker远程拉取消息，并放入到缓存中当客户端调用poll拉取消息时，会从缓存中拿结果并返回。

GroupCommitRequest对象在构建的时候是传入两个参数的，第一个是当前请求的下一个消息的偏移量，第二个是刷盘的超时事件，第一个参数后边判断同步是否结束会使用到。我们在这个判断中看到会遍历GroupTransferService的读队列，我们commitLog中添加的队列是写队列，经过this.waitForRunning(10)的读写队列对换，数据已经转移到了读队列。这段逻辑主要是判断当前主从同步是否结束，如果当前主从同步任务结束，唤醒当前等待数据同步完毕的线程，设置同步结果。

消息存储超过500ms算超时但是并不会报错，只会打一个warn日志commitLog刷盘逻辑是加锁的，并且有可重入锁和cas两种方式选择消息存储并不是一开始就落盘，而是尝试添加到MappedFile文件的尾部刷盘逻辑要根据配置来判断是同步刷盘或者异步刷盘，其中刷盘方法又分为flush和commit用调用HAService服务进行主从同步RocketMQ源码学习六：Producer端消息发送。

发送消息前会对topic和消息体做校验，消息不能大于4m，topic名称长度不能大于127发送过程中如果异常，使用for循环的方式做了重试。同步发送的重试次数是3，异步发送的重试次数是1发送前会初始化topic路由信息，里边包含发送的broker地址，对应的队列，读写队列的个数等信息如果发送失败的会放到故障延时队列，重试时topic会尝试拿上次失败的broker发送设置uniqID，用于判断消息发送是否重复发送，延迟发送，超前发送。

producer的启动首先也是初始化加载一些信息，比如加载producerGroup，创建MQClientInstance，初始化topicPublishInfoTable注册表启动的时候第二部就是拉取nameServer地址，因为后续的topic信息也是需要到nameServer上去拉取的启动各种定时任务，包括拉取nameServer地址，topic路由信息的拉取，发送心跳信息等同事也会启动PullMessageService线程，这里主要是拉取消息的逻辑，后期会相信学习。

broker也有一个BrokerController，这个是和nameServer一致的。BrokerController封装了很多关于broker的逻辑，比如:broker的初始化，线程池的初始化，通讯组件的初始化，注册各种处理器，初始化各种存储组件等等。broker的启动实际就是调用BrokerController的start()逻辑，也就是初始化各种组件。因为底层是依据netty做通信，底层就是启动一个netty做网络通信。

Consume Queue是按照消息的顺序进行存储的，每个消息队列都有一个对应的Consume Queue。Consume Queue相当于kafka中的partition，是一个逻辑队列，存储了这个Queue在CommiLog中的起始offset，log大小和MessageTag的hashCode。Commit Log是一个顺序写入的消息存储文件，它记录了每个消息的详细信息，包括消息的主题、标签、消息体等。每个消息队列都有一个对应的索引文件，其中记录了消息的关键信息，如消息的偏移量、消息的存储时间戳等。

namesrv这两个类是入口，一是：NamesrvStartup启动类，这里会加载配置信息，初始化定时任务；二是：DefaultRequestProcessor类，这个类承接所有的请求。通过类BrokerHousekeepingService我们也知道RocketMQ通信是通过netty实现的，后期也可以学习下netty相关的源码。RouteInfoManager路由类是主要的逻辑所在地，对cluster、broker、topic的操作主要在这个类中。

2015年，RocketMQ在消息传递方面迎来了一批重量级功能发布，包括事务消息、SQL过滤、轨迹追踪、定时消息、高可用多活等，以满足阿里巴巴日益丰富的业务场景。由于这些优势，RocketMQ 取代了阿里巴巴自主研发的另一款MQ产品Notify，成为阿里巴巴的首选消息中间件，实现了内部应用的百分百接入。RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，专为万亿级超大规模的消息处理而设计，具有高吞吐量、低延迟、海量堆积、顺序收发等特点。在同一年，阿里巴巴正式开源了RocketMQ的第一个版本。