消息中间件

背景：为什么是 MCP + Spring AI? 近期，MCP协议在全球范围内引起了广泛关注。 它旨在为大型语言模型（LLM）与客户端应用程序之间的交互提供一个标准化、可扩展的协议。 简单来说，MCP

源码版本 5.1.0 背景 RocketMQ的磁盘还是很重要的监控参数，如果RocketMQ集群磁盘出现了暴增，比如从50%增大到80% 甚至90%，会出现什么问题呢？？ 我们什么时候该扩容磁盘，达到

RocketMQ版本 5.1.0 文件类型 RocketMQ目前主要是三种文件 commitlog consumequeue index 源码入口 org.apache.rocketmq.store.

背景 最近同事发现线上发送的RocketMQ消息太大，同事为了节省网络带宽和存储空间，手动压缩消息然后再进行消息发送，发现磁盘也没有明显的缩减 所以我打算结合源码告诉他RocketMQ自带的消息压缩

背景 我们先看看我们的client和server通信的这么一种场景 client和server需要保持长连接。然后无论客户端还是服务端出现异常重启。我们都希望长连接都应该具备重试保活。 HTTP2中是

背景 团队小伙伴突然找到我们团队说，不得了了，线上的RocketMQ又出现了消费停滞，怎么办？ 要不要我们先重启一下 其实早在之前也出现过一次，当时为了快速恢复业务的，就直接重启解决的。 这次因为堆积

背景 有时候为了一些效率方面的考虑，我们可能会需要批量发送消息，或者批量消费消息。这里我们主要讨论批量发送消息的问题。 消息批量发送 消息批量发送很简单，官方文档也有例子，这里我们直接看代码 这里Na

RocketMQ version 5.1.0 背景 线上RocketMQ偶尔出现从Nameserve获取元数据TimeOut 查看Nameserve发现打印大量NETTY CLIENT PIPELIN

JVM监控选型 本次JVM监控我们采用prometheus官方提供的jmx_exporter来实现 RocketMQJVM开发 整体目录 1. 新增agent目录 我们在distribution目录新

背景 延时消息目前的实现目前有两种方式 旧版本的延时消息，仅支持固定时间的延时消息 5.0基于时间轮重新设计支持任意时间的延时消息 这里我们要讨论的还第一种延时消息 延时消息投递 延时消息投递后比如通

背景 最近线上偶发少量报错 问题排查 通过相关的报错可以发现是消息发送超时了。 具体是哪里超时了还要继续深入分析 源码分析 这里我们首先来看看源码大致会在哪里超时 全局搜索sendDefaultImp

背景 最近在研究RocketMQ消息不丢失的一些细节，所以关注到了5.x的一个新参数allAckInSyncStateSet 消息一个不丢的代价很大，我们需要再消息丢失和性能之间找到一个平衡，在保证性

RocketMQ version 5.1.0 脑图总览 实际存储文件 消息实际存储文件 commitLog 消息实际是存储在commitLog里面.里面没有区分topic和queue 存储结构的定义如

背景 早期在使用RocketMQ的时候，系统和开发人员不算多。所以topic的创建会非常随意，各种千奇百怪的topic 比如: order_topic、ORDER_TOPIC、order-topic

什么是BitSet 简单理解就是位图，类似BitMap。用来存储二进制位的类 BitSet特性 位存储：BitSet 以位为单位存储数据，每个位只能是 0 或 1。 空间效率：BitSet 比使用 b

RocketMQ版本 5.1.0 普通消息 消息重试的的实现分并普通消息和顺序消息。两者的重试机制大同小异。我们这里先看看不同消息 这里是官网定义的消息重试次数以及时间间隔。 有没有发现一个问题，这个

背景 当前的消费负载均衡策略是以队列的维度来进行，所有行为全部是由客户端主动来完成，主要分为三步： 每个consumer定时去获取消费的topic的队列总数，以及consumer总数 将队列按编号、c

背景 最近在查看消费进度的时候发现pop消费的GID查看不到消费进度，所以想一探究竟。为啥push、pull消费方式可以查看到，pop不行 RocketMQ版本 5.1.0 功能入口 在官方dashb

背景 最近在使用kafka的时候遇到了一些性能问题。 所以就打算研究下kafka相关的性能优化方案。 client主要分两个 producer consumer producer producer主要

背景 如果要自建kafka，那么一款功能齐全好用的dashbaord是必不可少的。 主流的kafka dashbaord 这里简单调研了下主流的dashbaord Know Streaming 滴滴开