smart_an的专栏

本章，我们介绍了RocketMQ中的延时消息，这是一个非常有用的功能。当订单系统的订单数量非常多时，我们完全可以部署几个“订单扫描服务”，然后订阅订单消息的Topic，这样就可以很高效的处理这类状态补偿问题。

本章，我们介绍了RockectMQ中的顺序消息，并以此解决了我们的背景案例中的一个遗留问题——大数据传输问题。在RocketMQ中，提供了两种类型的顺序消息：全局顺序消息、分区顺序消息。读者可以自行参考RocketMQ的官方文档进行学习。

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。本章，我们来看下RocketMQ中的重复消费问题。

本章，我们对消息丢失的三类场景进行分析，并给出了一套消息零丢失的全链路解决方案，对RocketMQ中的事务消息机制原理进行了详细讲解。在业务系统中，使用事务消息机制会大大降低吞吐量，所以一般建议，对于涉账类以及核心数据相关的交易链路或系统，可以采用上述这套消息零丢失方案。而对于其它大部分没那么核心的场景和系统，其实即使丢失一些数据，也不会导致太大的问题，不建议采用这套方案。一般来说，对于大多数系统，生产者通过同步发送消息+反复重试的方式，就可以做到99%场景下的消息可靠投递。

Reactor主线程在端口上监听Producer建立连接的请求，建立长连接；Reactor线程池并发的监听多个连接的请求是否到达，到达则转发请求；Worker请求并发的对多个请求进行预处理；业务线程池并发的对多个请求进行磁盘读写等业务操作。通过“专人专事”的模式， 这样一套网络通信架构，最终实现的效果就是可以高并发、高吞吐的对大量网络连接发送过来的大量请求进行处理，这是保证Broker实现高吞吐的一个非常关键的环节。

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。

RocketMQ中Broker的高可用机制，整体还是比较容易理解的，很多开源框架都利用了Raft算法的思想来实现高可用，比如Redis、Zookeeper，都是Raft算法或其变种。这里，有童鞋可能要问了，万一整个Broker集群都挂了怎么办？这种情况事实上就相当于MQ彻底崩溃了，这个时候其实就需要另一种高可用的架构思路了，即业务系统自身的高可用。通常这时要用降级方案，将MQ的依赖暂时从业务系统中排除出去，比如将原先发送到MQ里的消息发送到缓存中，或者暂时存储到本地磁盘。

本章，我们深入讲解RocketMQ的持久化机制，其核心就是：CommitLog保存消息内容，ConsumeQueue保存消息地址——offset。顺序写入消息内容至磁盘文件尾；将消息先写入PageCache，然后异步刷盘；利用mmap技术进行内存映射，以减少数据拷贝次数；提前加载磁盘文件内容到PageCache中，进行文件预热，提升读取效率。

本章，我们针对案例系统中存在的部分问题进行了分析，并通过RocketMQ对其进行了改造。消息中间件的核心功能就是异步、解耦、削峰。后续章节，我们会继续解决案例中剩余的几个问题。另外，引入MQ后其实也会带来整个系统的复杂度上升，比如消息丢失问题、消息有序问题、数据一致性问题等等，我会在后续章节一一讲解。

通过上述压测，我们可以看到，整个RocketMQ集群的性能瓶颈其实在网卡上，当TPS达到7万时，cpu、内存、IO负载都在正常范围，GC频率也正常。所以，针对我们自己的机器配置，理论上RocketMQ集群的负载上限是7w。

本章，我们通过一个示例讲解了RocketMQ如何进行部署，主要分为NameServer部署和Broker部署，复杂点主要在于Broker部署时的配置。当我们部署完RocketMQ，是否就可以直接迁到生产环境使用了呢？显然不是的，我们需要调整Broker的OS内核参数、JVM参数进行优化，然后进行性能压测，确认在当前物理架构下，RabbitMQ的极限负载，然后再确定是否以当前物理架构上生产。

本章，我们介绍了RocketMQ的基本架构，并对其中的NameServerBrokerProducerCustomer这四个核心组件进行了简要讲解。RocketMQ实现高可用和可扩展的思路其实没什么新意，就是基于Raft协议的主从架构，以及数据分散集群模式。如果读者对Spring Cloud有所了解，就会发现，RocketMQ的基本架构和Spring Cloud中的很多组件非常相似，比如NameServer，其实就是类似于Spring Cloud中的Eureka服务注册中心。

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。本系列的第一篇，我们先来看下消息中间件能做些什么？

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

学习必须往深处挖，挖的越深，基础越扎实！阶段1、深入多线程阶段2、深入多线程设计模式阶段3、深入juc源码解析阶段4、深入jdk其余源码解析阶段5、深入jvm源码解析码哥源码部分码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】码哥源码-原理源码篇【Doug Lea为什么要将成员变量

当一条消息初次消费失败，消息队列会自动进行消费重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。这个队列就是死信队列（Dead-Letter Queue，DLQ），而其中的消息则称为死信消息（Dead-Letter Message，DLM）。死信队列是用于处理无法被正常消费的消息的。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

i < 10;i < 10;

/ 消息列表分割器：其只会处理每条消息的大小不超4M的情况。// 若存在某条消息，其本身大小大于4M，这个分割器无法处理，// 其直接将这条消息构成一个子列表返回。并没有再进行分割// 指定极限值为4M// 存放所有要发送的消息// 要进行批量发送消息的小集合起始索引@Override// 判断当前开始遍历的消息索引要小于消息总数@Override// 记录当前要发送的这一小批次消息列表的大小for (;// 获取当前遍历的消息。

/ 回调操作方法// 消息预提交成功就会触发该方法的执行，用于完成本地事务@OverrideSystem.out.println("预提交消息成功：" + msg);// 假设接收到TAGA的消息就表示扣款操作成功，TAGB的消息表示扣款失败，// TAGC表示扣款结果不清楚，需要执行消息回查// 消息回查方法// 引发消息回查的原因最常见的有两个：// 1)回调操作返回UNKNWON// 2)TC没有接收到TM的最终全局事务确认指令@Override。

当消息写入到Broker后，在指定的时长后才可被消费处理的消息，称为延时消息。采用RocketMQ的延时消息可以实现定时任务的功能，而无需使用定时器。典型的应用场景是，电商交易中超时未支付关闭订单的场景，12306平台订票超时未支付取消订票的场景。在电商平台中，订单创建时会发送一条延迟消息。这条消息将会在30分钟后投递给后台业务系统（Consumer），后台业务系统收到该消息后会判断对应的订单是否已经完成支付。如果未完成，则取消订单，将商品再次放回到库存；如果完成支付，则忽略。

顺序消息指的是，严格按照消息的发送顺序进行消费的消息(FIFO)。默认情况下生产者会把消息以Round Robin轮询方式发送到不同的Queue分区队列；而消费消息时会从多个Queue上拉取消息，这种情况下的发送和消费是不能保证顺序的。如果将消息仅发送到同一个Queue中，消费时也只从这个Queue上拉取消息，就严格保证了消息的顺序性。

/ 创建一个producer，参数为Producer Group名称// 指定nameServer地址// 设置当发送失败时重试发送的次数，默认为2次// 设置发送超时时限为5s，默认3s// 开启生产者// 生产并发送100条消息i < 100;i++) {// 为消息指定key// 发送消息// 关闭producer// 消息发送的状态// 发送成功SEND_OK,// 刷盘超时。当Broker设置的刷盘策略为同步刷盘时才可能出现这种异常状态。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费过程就是消费幂等的。幂等：若某操作执行多次与执行一次对系统产生的影响是相同的，则称该操作是幂等的。在互联网应用中，尤其在网络不稳定的情况下，消息很有可能会出现重复发送或重复消费。如果重复的消息可能会影响业务处理，那么就应该对消息做幂等处理。

1）对于RocketMQ系统来说，删除一个1G大小的文件，是一个压力巨大的IO操作。在删除过程中，系统性能会骤然下降。所以，其默认清理时间点为凌晨4点，访问量最小的时间。也正因如果，我们要保障磁盘空间的空闲率，不要使系统出现在其它时间点删除commitlog文件的情况。消息是被顺序存储在commitlog文件的，且消息大小不定长，所以消息的清理是不可能以消息为单位进行清理的，而是以commitlog文件为单位进行清理的。联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！这里的offset指的是Consumer的消费进度offset。消费进度offset是用来记录每个Queue的不同消费组的消费进度的。根据消费进度记录器的不同，可以分为两种模式：本地模式和远程模式。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！订阅关系的一致性指的是，同一个消费者组（Group ID相同）下所有Consumer实例所订阅的Topic与Tag及对消息的处理逻辑必须完全一致。否则，消息消费的逻辑就会混乱，甚至导致消息丢失。

Rebalance即再均衡，指的是，将⼀个Topic下的多个Queue在同⼀个Consumer Group中的多个Consumer间进行重新分配的过程。Rebalance机制的本意是为了提升消息的并行消费能力。例如，⼀个Topic下5个队列，在只有1个消费者的情况下，这个消费者将负责消费这5个队列的消息。如果此时我们增加⼀个消费者，那么就可以给其中⼀个消费者分配2个队列，给另⼀个分配3个队列，从而提升消息的并行消费能力。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！RocketMQ中的消息存储在本地文件系统中，这些相关文件默认在当前用户主目录下的store目录中。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！RocketMQ有一个可视化的dashboard，通过该控制台可以直观的查看到很多数据。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

NameServer是一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现。RocketMQ的思想来自于Kafka，而Kafka是依赖了Zookeeper的。所以，在RocketMQ的早期版本，即在MetaQ v1.0与v2.0版本中，也是依赖于Zookeeper的。从MetaQ v3.0，即RocketMQ开始去掉了Zookeeper依赖，使用了自己的NameServer。Broker管理：接受Broker集群的注册信息并且保存下来作为路由信息的基本数据；