消息中间件

RocketMQ 版本 5.1.0 长轮训 一般常用的客户端和服务的交互方式有如下两种方式 短轮训 长轮训 短轮训: client不断向服务端发送请求，服务端不管有没有数据，都返回给client。 优

背景 在上次记一次RocketMQ线上broker内存持续升高问题排查 之后得出了一个结论 JKD8 G1在经历一次Full GC后就会归还内存给操作系统 实际最近也在做RocketMQ缩容的事情，所

RocketMQ 版本 5.1.0 背景 大促期间为了保证RocketMQ的稳定性，进行了扩容，扩容实战相关的操作博文之前也提到过 可以参考这里 RocketMQ无损扩容实战 :https://wei

RocketMQ 版本 5.1.0 jdk版本 1.8 JVM启动参数 现象 部署RocketMQ的linux宿主机内存持续升高。由50%升高到80% 排查 线程资源占用情况 由于宿主机上面只部署了一

netty version 4.1.65.Final ChannelPipeline 是什么 Pipeline，管道、流水线，类似于责任链模式。基本上我们使用Netty开发程序需要编写的就是Chann

Kafka版本 kafka_2.13-3.5.0 背景 Kafka 默认消息存储时间为7天，实际线上的业务使用Kafka更多的是一些数据统计之类的业务，大多是朝生夕死，大概存储1-3天就可以了。为了节

RocketMQ 版本 5.1.0 RokcetMQ消息过滤 目前官方支持的消息过滤方式主要有两种 tag sql92 我们可以通过查看ExpressionType的源码证明 tag过滤方式是现在最为

最近在看RocketMQ的一些监控指标的时候，总觉得一些监控指标不太对，好像对不上。 所以打算研究下看看RocketMQ中的 broker TPS、broker QPS,producer TPS 这些

背景 继上次分析RocketMQ线上各种system busy 比较合理能提升性能和缓解system busy的方法就是修改broker的配置为transientStorePoolEnable = t

RocketMQ 版本 5.1.0 背景 继之前研究过的RocketMQ发送消息还有这种坑？遇到SYSTEM_BUSY不重试？ 今天我们来分析分析RocketMQ什么情况下会出现system busy

kafka版本 kafka_2.13-3.5.0 背景 继之前Linux Kafka 3.5 KRaft模式集群部署:https://weihubeats.blog.csdn.net/article/

Kafka version kafka_2.13-3.5.0 Kafka 监控 Kafka自带JMX监控 JMX我们不用过多介绍，如果你用过Spring Boot Actuator就算用过JMX，Sp

RocketMQ 版本 5.1.0 背景 测试环境的RocketMQ总会在运行一段时间后，莫名其妙就挂掉，刚开始以为就是简单的内存不够导致的 因为测试环境给的资源不多，但是时间久了总需要重启也麻烦。总

背景 kafka在KIP-500引入了KRaft替代Zookeeper来实现自我管理元数据 详细信息可以看原文链接 KIP-500 KRaft简介 KRaft是kafka用来取代zookeeper的分

缘起 访问线上的RocketMQ集群的dashboard突然上不去了提示超时 初次排查 看报错很清晰可以看到就是timeout 所以最简单的是增加了超时时间(我多等一会)，从5s增加到10s，15s

背景 最近在排查RocketMQ一个网络问题的时候，排查到了Netty相关的处理，然后看到了RocketMQ在构建workGroup的时候，发现了有如下代码 可以看到有一个很核心的判断 这里判断是否使

背景 最近在维护RocketMQ经常会出现这种问题 消息发送方和接收方出现扯皮，消息发送方说我的消息已经发送成功了，消费方说我没接收到消息。两边各持己见，谁也不会说服谁。这时候就非常希望RocketM

RocketMQ版本 5.1.0 背景 我们都知道RocketMQ 5.x新增了proxy模式部署方式，也就是支持了GRPC的消费方式消费，所以今天我们来试试 本次使用的开发语言是goland 前置条

RocketMQ版本 5.1.0 背景 入口 这里源码入口我们就从broker启动开始查看吧，然后慢慢到NameServer 由于不知道具体代码在哪，所以我们就漫无目的的找找看吧 想了下算了还是直接搜

RocketMQ版本 5.1.0 背景 首先说明本次源码分析仅分析时间轮之前的延时消息设计 延时消息基础知识 默认RocketMQ延时消息共有18个等级 延时消息的简单使用 发送延时消息 和普通消息不