念念不忘，必有回响

总的来说java应用都支持使用prometheus官方提供的这个agent来实现JVM的监控。我们只需要修改一下脚本把agent挂载上去即可。

老版本的延时消息默认是存储在这个topic，直接去原始topic查询消息是查询不到的然后查询到延时消息想通过官方dashboard直接查看原始的topic也是不支持的如果我们想查看延时消息具体是哪个topic的。我们可以通过方法获取MessageExt对象，然后通过MessageExt对象获取propertiesproperties中就有原始的topic信息。

首先我们可以确定的是发生是还没有发送消息就超时了导致的。发生超时主要应该是在获取topic元数据导致的那么导致超时的原因可能有哪些呢？topic第一发送消息多个线程获取topic元数据信息同步等待锁后又重新从Nameserver获取导致的超时topic第一发送消息获取topic元数据真正的网络延时导致的超时(这种情况可能比较少，因为一般RocketmQ和client都是在一个内网)JVM Full GC stop the world导致的超时。

总的来说开启最多会在master宕机后15s内集群写入不可用，等异常的broker被移出后就可以继续正常写入了。实际比如有三个集群broker-abroker-bbroker-c一个集群比如broker-a在15s内不可写入也是可以接受的，因为还有两个集群可以写入,product也是有消息重试的。所以如果不开启。一条消息写入master后还没来得及同步给slave就宕机，消息丢失的风险还是太大,线上还是推荐开启。

RocketMQ的消息文件主要存储在commitLog，为了保证高性能的读写，commitLog采用顺序写入，文件名按偏移量命名，这样通过二分查找消息的效率非常高。由于订阅模型是基于topic的所以为了提高性能又引入了类似commitLog的索引，并不会直接存储消息，只存储了消息的物理偏移量，这样可以很方便的通过定位到commitLog为了支持按key查找，RocketMQ又引入了索引文件IndexFile，用来支持按key的查询。索引文件主要是利用hash，通过对。

早期在使用RocketMQ的时候，系统和开发人员不算多。所以topic的创建会非常随意，各种千奇百怪的topic

简单理解就是位图，类似BitMap。用来存储二进制位的类总的来说BitSet在一些特定场景使用还是非常节省内存高效的。

普通消息重试默认是16次，顺序消息默认是，消息消费失败会以延时消息的方式投递到broker，超过延时消息的最大值则以2小时为重试间隔。现在提供了不同的重试策略，默认是如果broker投递失败则会在本地再次消费该消息.重试次数的元数据存储在重试次数的增加有两种发送到broker后在broker进行+1(broker重试)如果发送broker失败则在本地消费进行+1(client重试)

popRebalance在broker实现，方便多语言client实现维护.更符合云原生单个客户端消费所有queue,避免单个client假死造成消息堆积避免出现因为queue不足导致的扩展consumer提升消费能力异常避免消息队列数量与consumer数量比例不均衡时导致的某些consumer承担过多的消息后续有机会再分析下pop消费时间的源码以及更多细节。

总得来说官方dashboard对于pop的消息查询存在bug。因为获取broker的地址信息是通过查询重试topic的路由信息获取到的，如果没有重试topic就查询不到broker消费进度。因为pop的重试队列规则修改了。旧版本的dashboard没有兼容所有会查询不到。

总的来说消息拉取这一块的源码还是非常复杂的，我们只能走马观花查看整体流程。没办法一一俱到分析所有的细节，不然我们会迷失在复杂的源码海洋中。我们先理清整理逻辑即可。这里我们再总结下我们分析到的流程client向broker发送消息拉取请求broker如果没有消息则会将请求挂起挂起的请求有几个处理机会a. 默认会有定时5s去轮训处理这些暂存的请求b.会每隔1毫秒去检查是否有消息到来，如果有则分发新的消息到来，其中就包括处理hold住的请求。

所以总结来说JKD8 G1在经历一次Full GC后就会归还内存给操作系统的前提是-Xms和-Xmx参数设置大小不一致才会归还。如果设置一样大即使经历Full GC也不会归还给到操作系统至于验证下次有机会在线上再验证下吧，网上也有很多人都验证了，这里就不验证了。

总的来说缩容还是比较简单的，就是broker停写，然后等broker上面的消息都消费完成后即可下线。下线的时候先下线slave，然后是master。避免出现主从自动切换。

进程在申请内存的时候，不是直接分配物理内存，分配一块虚拟空间，等到堆真正使用这块虚拟空间才会发生缺页去分配物理内存。

本次我们对RocketMQ sql92过滤消息进行了简单的使用以及少量的源码分析，并没有完整的从整个流程进行分析，因为本篇并不是源码分析偏。sql92在实际的项目中的相对来说较少，偶尔如果做RocketMQ消息的多册环境或者灰度，可能是一个方案，但不是最佳的。

总的来说一般一条消息会被多个业务方消费，所以QPS都是会大于TPS的。TPS主要是统计写消息量QPS主要是统计读(消费)消息量主要注意的是官方目前的统计是有一个小bug的统计的一些QPS、TPS改成统计的是TPM。所以如果要修复这个bug可以参考这个pr相关讨论可以参考这个issues。

总的来说开启读写分离有明显的QPS性能提升，但是会耗费额外的内存，但是每条消息的平均耗时变高了。

本次我们结合源码分析了出现的四种情况broker中消息发送线程池()处理任务超时OS page cache is busy，开始清理送线程池()中的queue任务消息发送线程池()队列容量满了(默认1w)如何缓解这几种异常呢？本质都是broker的压力太大了，处理不过来。最好的解决方式就是提升broker的处理速度，即RocketMQ的 QPS。有以下几种方式开启读写分离(即transientStorePoolEnable = true)扩容broker集群优化broker。

目前来看5.1.0之前的版本可能都有这个问题。所以大家在实际使用的时候一定要注意自己的RocketMQ这个bug是否修复了.不过影响说大不大，说小不小。因为master和slave频繁建立连接本身也有问题。

这里真相水落石出了，主要是还是线程池被打满堆积了太多任务导致的如何处理呢增大线程池减少对线程池的请求线程池添加监控broker添加相关的请求限流。

总的来说网上大多说明在linux性能是更高于,但暂时没有找到相关的基准测试数据。总的来说在linux上面使用似乎是更优的选择，所以我们在部署RocketMQ的时候我们可以将参数配置为true。

这里是weihubeats,觉得文章不错可以关注公众号，文章首发。拒绝营销号，拒绝标题党。

总的来说消息轨迹开启后会非常方便我们定位问题，但是会增加额外的存储开支，如果消息量很大，推荐使用物理隔离的方式，单独使用一个broker存储消息轨迹。

可以看到我们使用GRPC的方式消费和发送消息都成功了，但是需要注意的是目前还不是很稳定，有一些bug，生产使用还是需要谨慎。

总的来说就是broker启动后会向所有的Nameserver注册自己的相关元数据信息，然后定时发送心跳。如果执行修改topic相关的信息，也会同时更新broker和`Nameserver·上面的元数据信息。

总的来说延时消息就是默认分为18个队列，然后启动18个线程一直去扫描这18个队列。如果没有消息就过100毫秒继续重复扫描，周而复始如果扫描到消息则将延时消息Topic中的消息取出来,然后重新转换为原始消息，包括原始消息的Topic和queueId，然后重新写入到commitLog中。

这里是,觉得文章不错可以关注公众号，文章首发。拒绝营销号，拒绝标题党。

这里是,觉得文章不错可以关注公众号，文章首发。拒绝营销号，拒绝标题党。

总的来说RocketMQ执行文件清理操作主要是在设置的凌晨4点(4:00-5:00),要清理的文件也是我们常见的CommitLogIndex清理的条件就是三个磁盘超过设置的默认85%到达设置的清理时间默认凌晨4点手动执行清理操作三个条件满足一个即可至于一些文件操作比如等不在本次探讨范围内，限于篇幅我们这次是看整理的逻辑。后续会基于单个点深入分析。

我们本次以源码的方式启动了3个Nameserve+2个broker其中还包含3个controller+2个proxy后续我们需要debug观测RocketMQ集群的源代码就非常方便了。

总的来说整体操作难度不大，但是如果认为的去扩容在线上遇到紧急流量我们可能操作不过来，所以可以考虑使用快照的方式扩容这样库容会更快。

总的来说RocketMQ的消费位点如果是客户端管理，重置消费位点是由客户端发起，发送到broker，最终还是由broker去通知所有broker去更新本地消费位点。

本文我们主要学习了是什么，以及核心组件，还有如何使用，不涉及原理和源码的分析。在知道了如何使用后我们后面才会去分析源码。

可以看到整个步骤是非常繁琐的，所以我们需要写一个简单的部署脚本来简化我们的操作。发现一个问题，如果我们需要部署一个新的集群需要干什么事情呢？注意这里你需要将git的下载地址换成你自己实际的下载地址。我们要使用的部署脚本很简单，就是自动帮我们安装。然后就可以执行这个脚本，帮我们自动安装。注意在使用的时候我们仍然需要手动去。

这里是weihubeats,觉得文章不错可以关注公众号，文章首发。拒绝营销号，拒绝标题党。

这里我们详细介绍了client是如何触发Rebalance的，以及触发Rebalance的时机，也介绍了Rebalance的好处。实际还有很多细节我们限于篇幅暂未分析。后面我们会继续分析Rebalance的坏处和一些详细的Rebalance算法。

由于我们在使用查询的时候底层帮我们屏蔽了msgId和，导致我们不会去细分二则的区别consumer调用toString方法打印出来的msgId实际是，所以会与product中的msgId对不上，因为product中的msgId实际是UniqKey。

这里是weihubeats,觉得文章不错可以关注公众号，文章首发。拒绝营销号，拒绝标题党。

这个项目是干嘛的呢？就是给prometheus提供数据源，让prometheus可以通过该项目采集到rocketmq的一些监控指标，然后做监控告警总的来说这个项目整体结构还是比较简单的，上手难度也比较低也有一些弊端。监控上报的指标可能不全已经基本不再维护所有的定时任务都是单节点的，不支持多节点部署使用的版本还是4.x。

至此RocketMQ的一些监控指标的处理就分析完成了，我们从指标的获取->写入->统计都分析到了。包括如何添加我们自己的监控指标，当然一些小细节就限于篇幅就没具体分析比如，统计计数使用的LongAdder而不是AtomicLong等。