念念不忘，必有回响

总的来说改动还挺多，最核心的改动还是默认使用KRaft模式运行。和也有一些改动，具体参考官网吧。

如果kafka能正常发送消息，但是消费异常，一般是消费位点出现了问题，即管理消费位点的这个toipc目前来看新增了3个brokerkafka并没有自动对进行分区迁移，需要手动进行迁移所以后续出现消费相关的问题可以优先检查这个topic的情况,毕竟kafka得消费位点都依赖于这个topic。

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

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

其实可以看到producer的batch.size和linger.ms就是借鉴了tcp/ip的网络发送算法。tcp/ip的Nagle算法大致的规则如下如果包长度达到MSS，则允许发送如果包含FIN，则允许发送如果设置了TCP_NODELAY，则允许发送未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送上述条件都未满足，但发生了超时（一般为200ms），则立即发送。elseelseend ifend ifend if总得来说主要是四个参数。

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

总的来说Kafka的配置分broker级别和Topic级别。如果我们要修改消息的存储时间，最好是通过修改Topic的存储时间来修改，因为不用重启broker。不过在部署Kafka集群的时候我们也建议设置合理的消息存储时间，避免每个Topic都要定制化配置，才能最大化利用磁盘，避免磁盘浪费其次从Kafka的这种配置设计来说，我们后续做技术设计的时候也可以采用这种优秀的方式，提供全局+局部的配置，局部配置优先级高于全局，其实如果开源软件使用的多的话，我们会发现大多开源软件的配置都采用这种设计思路。

本次我们对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频繁建立连接本身也有问题。

KRaft是kafka用来取代zookeeper的分布式协调管理组件。

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

总的来说消息轨迹开启后会非常方便我们定位问题，但是会增加额外的存储开支，如果消息量很大，推荐使用物理隔离的方式，单独使用一个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去更新本地消费位点。

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

总的来说部署还是相对简单，线上部署nameserver还是推荐最少3个节点，然后就是内存调大一点，nameserve不要和broker部署在一起。

至此我们就分析完了topic创建、更新流程，我们总结一下client循环向集群中的所有masterbroker注册topic信息broker接受到创建或更新topic信息后本地创建topic然后写入本地文件中，同时会更新broker的内存topic信息，然后向所有nameserver更新topic信息可以看到整体逻辑还是很清晰的。

客户端每隔30s就会去扫描判断Nameserver是否存活客户端每隔2分钟才会去http服务器拉取最新的Nameserver地址客户端topic相关的缓存信息每隔30s会去Nameserver拉取最新的topic、broker相关信息。

这里我们通过源码的方式验证了rocketmqproduct获取的几种方式，其中最推荐的还是通过HTTP服务来获取，因为可以自由扩容。

总的来说开源的和阿里云的差异还是挺大的，核心还是运维。自建需要自己搭建整个RocketMQ集群，并且RocketMQ没有合适好用的dashboard，基本功能RocketMQ5.x都是满足的，已经支持了任意秒级别的延时消息，也支持GRPC的接入方式。但是在扩容和监控方便仍然需要我们自己去自研开发。

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

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

文章目录源码版本消息发送源码源码入口消息发送核心源码Product发送消息的重试机制Broker故障转移机制选择MessageQueue源码总结关于我源码版本4.8.0消息发送源码源码入口最简单的消息发送代码 DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name"); producer.setNamesrvAddr("127.0.0.1:9876");

文章目录源码版本官方提供的Consumer消费消息的demo代码客户端消息的拉取带注释的源码地址参考关于我源码版本4.8.0官方提供的Consumer消费消息的demo代码 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4"); // 1. 设置 NamesrvAddr 地址 consumer.setNamesrvAddr(

文章目录背景设计思路具体实现定义一个幂等注解定义一个AOP切面使用项目源码地址不足背景目前项目中RocketMQ应用场景还是比较多的，但是线上经常因为一些异常原因导致生产者重新投递消息导致消费者消费重新消费，为此每次需要手动处理消费幂等，觉得比较繁琐，所以就想了写一个通用的自动幂等框架设计思路开始是想着借用Redis或Mysql作去重幂等校验，大致思路如下大致流程如下，其中加锁部分在redis就直接使用redis的分布式锁即可，在Mysql中加锁可以基于for update来实现最开始的实现是

文章目录说明适用场景实现方案本地消息表实现方案原理基于RocketMQ事务消息实现原理异常情况说明实现伪代码参考说明可靠性消息最终一致性是分布式事务解决方案中的一种典型的柔性事务解决方案,不保证数据的强一致性，只保证数据的最终一致性适用场景及时性要求不是很高的能接受数据暂时的不一致情况实现方案本地消息表 + MQ普通消息基于RocketMQ事务消息实现本地消息表实现方案原理事务发起方向业务数据表写入数据，同时向本地消息表写入一条消息数据，由于业务数据表和本地消息表在同一个事务

文章目录入口核心流程BrokerController是如何被创建的入口Broker启动的源码入口是BrokerStartup.java核心流程住流程和NameServer有些类似创建BrokerController启动BrokerControllerpublic static void main(String[] args) { start(createBrokerController(args)); } public static BrokerCont

文章目录入口NamesrvController是如何被创建出来的启动NameServer入口NameServer 源码的启动入口在类NamesrvStartup中的main方法中可以看到方法封装的非常好，每个方法干一个事。核心方法就是这两个 NamesrvController controller = createNamesrvController(args); start(controller);NamesrvController是如何被创建出来的我们看看createNamesrv

文章目录Fork RocketMQ源码到本地仓库idea拉取自己仓库RocketMQ源码启动NameServer启动 Broker启动`Producer`生产消息启动`Consumer` 消费者总结Fork RocketMQ源码到本地仓库RocketMQ源码地址:https://github.com/apache/rocketmq首先我们将RocketMQ的源码fork到我们自己仓库，因为我们可能会对RocketMQ源码作一些改变，然后需要提交到我们自己仓库中，比如添加注释，但是我们不能直接推到Roc

文章目录消息会在哪里丢失生产者100%投递消息RocketMq100%不丢失消息Consumer 100% 消费消息消息会在哪里丢失在想要解决RocketMq消息丢失问题我们需要先考虑消息会在哪里丢失。我们从消息链路来依次排查生产者发送消息消息丢失RocketMq本身导致消息丢失消费者消费失败导致消息丢失在知道消息会在这三个地方丢失我们就好基于这三个地方来作出相应的解决方案生产者100%投递消息这里我们以订单支付为例，需要发送订单支付成功到优惠券系统首先我们需要保证生产者消息能够100