消息中间件

RocketMQ版本 5.1.0 背景 最近线上的RocketMQ集群遇到了如下问题，业务方的小伙伴反馈问题，说出现了 相关的错误导致发送消息失败。自信看过源码的我马上回复了别怕会重试 结果业务方的小

背景 在我们要平滑升级broker的时候，无损升级的最佳实践应该是 新broker启动 旧broker停写 旧broker消息消费完成后下线(包括延时消息) 所以我们本次就是来分析如何完成broker

RocketMQ版本 5.1.0 入口 这里消息删除的源码入口其实不太好直接确定，我们可以通过启动broker的代码开始即BrokerStartup的main方法 这里我们直接进入到controlle

背景 由于RocketMQ 5.x主从同步的方式改动非常大，集群部署的方式也改动很大，所以打算本地启动一个小集群，进行debug研究源码学习 RocketMQ版本 5.1.0 集群 打算本地启动3个N

背景 假设目前我们的线上部署的RocketMQ部署的是一主一从，现在随着业务的发展，或者是我们需要做一些促销活动，会有突发流量高峰，现有的一主一从无法满足我们的性能，服务器的内存和cpu占用已经高达7

背景 最近在使用RocketMQ的重置消费位点的时候经常出现报错，所以就打算研究下RocketMQ是如何重置消费者的消费位点的 RocketMQ版本 5.1.0 Dashboard: 最新github

官方文档 https://kafka.apache.org/quickstart 版本 3.5.0 安装 这里我们提供两种安装方式，一种是编译好的源码包安装，一种是傻瓜式的Docker compose

背景 线上的RocketMQ集群有运行一段时间了。比如测试环境和线上环境的RocketMQ集群部署的机器内存大小肯定不一样。所以可能要写多个部署脚本。非常麻烦 官方的部署脚本是不支持根据宿主机内存大小

背景 最近在看rocketmq-exporter源码，发现了rocketmq-exporter在管理rocketmq-client使用了一个apache的三方库commons-pool，所以打算研究下

背景 继上次我们学习了手把手教你从Linux源码开始部署RocketMQ 5.0 Cluster模式 发现一个问题，如果我们需要部署一个新的集群需要干什么事情呢？ 生成秘钥对 gitlab配置ssh公

背景 RocketMQ版本: 5.1.0 部署方式 报错 首选通过执行命令查看同步信息 发现有几个broker处于NotInSyncReplica状态 查看broker log信息 发现如下报错 核心

RocketMQ版本 version: 5.1.0 RocketMQ中consumer消费模型 在了解RocketMQ的Rebalance机制之前，我们必须先简单了解下rocketmq的消费模型 我们

rocketmq版本 5.1.0 现象 我们使用官方的发送消息和消费消息demo运行得到如下结果 消息发送 打印的结果如下: 可以看到几个重要信息 msgId: 0A0A003A4833251A69D

背景 线上服务器由于安全考虑，不会主动将所有的端口打开，所以我们在部署RocketMQ的时候需要整理用到的端口提供给运维，让他们在安全组中打开。 所以这里整理了一份RocketMQ 5.0用到的端口

背景 继上一次RocketMQ源码分析之监控指标分析之后，我们需要自定一些监控指标，那么我们就需要对开源项目 rocketmq-exporter进行一些二开,所以我们今天来研究研究rocketmq-e

Rocketmq版本 version: 5.1.0 背景 继续上次的高可用topic二开已经有了一段时间，现在我们需要对我们的限流数据进行监控，所以现在我们来研究研究RocketMQ的监控源码 入口

源码版本 5.1.0 背景 rocketmq 高可用设计中必不可少的就是限流，如果我们想让我们的rocketmq集群稳定不被客户端打爆，我们最好是在topic添加限流，防止某个topic的生产者异常发

Rocketmq版本 version: 5.1.0 部署架构 说明 该架构仅为测试环境部署方案 nameserver和controller同进程部署 broker和proxy同进程部署，采用的是Loc

源码版本 rocketmq:release-5.1.0 背景 继上一章我们分析了client端Nameserver地址更新的源码实现方式 现在我们继续研究client是如何创建更新topic并与bro

源码版本 rocketmq:release-5.0.0 背景 上一章我们通过源码的方式详细的介绍了client如何获取Nameserver地址，今天我们就来继续研究研究client是如何更新Names