目录RocketMQ的核心概念说明1. 模型关系1. 主题（Topic）1.1. 主题的内部属性：1.2. 使用建议2. 队列3. 消息3.1. 消息的内部属性4. 生产者5. 消费者组5.1. 内部属性5.2. 使用建议6. 消费者7.订阅关系7.1 .订阅关系判断原则7.2 .内部属性7.3. 使用建议RocketMQ主从复制&负载均衡策略1. 主从复制2. 生产者负载均衡策略3. 消
概念消息处理流程中，如果Consumer的消费速度跟不上Producer的发送速度，MQ中未处理的消息会越来 越多（进的多出的少），这部分消息就被称为堆积消息。消息出现堆积进而会造成消息的消费延迟。 以下场景需要重点关注消息堆积和消费延迟问题：业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。业务系统对消息的消费实时性要求较高，即使是短暂的堆积造成的消费延迟也无法接受。产生原因分析Consu
转载
2024-04-05 10:46:32
394阅读
概述这篇文章的目的主要是为了讲清楚rocketMq消息堆积的概念，我印象中的rocketMq的消息堆积应该分为两层，一层是broker中实际写入消息量和consumeQueue已经消费位移的偏差，另外一层consumer端本身已经拉取消息的堆积，而今天要讲的正是后者。这个问题的起源是当时有个其他公司的同事遇到consumer端不停的gc，然后开始谈论起这个话题，然后我就按照我的理解给他解释了一遍，
转载
2024-05-15 10:30:28
94阅读
这篇文章，我们聊聊如何应对 RocketMQ 消息堆积。1 基础概念消费者在消费的过程中，消费的速度跟不上服务端的发送速度，未处理的消息会越来越多，消息出现堆积进而会造成消息消费延迟。虽然笔者经常讲：RocketMQ 、Kafka 具备堆积的能力，但是以下场景需要重点关注消息堆积和延迟的问题：业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。业务系统对消息的消费实时性要求较高，即使是短暂的堆
转载
2024-06-20 10:05:17
411阅读
目录一、消息堆积问题二、解决消息堆积的三种思路三、惰性队列1、命令行修改惰性队列2、用SpringAMQP声明惰性队列@Bean的方式注解方式测试发送消息3、惰性队列的优点4、惰性队列的缺点代码 一、消息堆积问题当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，知道队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积的问题。二、解决消息堆积
转载
2024-04-09 15:16:52
195阅读
01 什么是消息堆积？字面意思：堆积，就是把事物堆积成堆。这里指的就是消息堆积在一起，一直没有被消费或消费的很慢。02 消息存储在哪？消息一般会存在 Broker 服务里面。这里拿我自己搭建的环境，我们来看看（因为我没做好文件映射关系，所以直接进去容器看），一般消息都会放在//store/里面，实体消息放在 commitLog 文件，consumequeue 是存放消息索引的。这个涉及到消息索引和
转载
2024-04-03 12:36:23
645阅读
文章目录一、背景二、MQ消息堆积三、消息堆积常见于以下几种情况：四、解决上述问题需要做到五、如何解决消息堆积和延迟问题 一、背景消息处理流程中，如果客户端的消费速度跟不上服务端的发送速度，未处理的消息会越来越多，这部分消息就被称为堆积消息。消息出现堆积进而会造成消息消费延迟。以下场景需要重点关注消息堆积和延迟的问题：业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。业务系统对消息的消费实时
转载
2024-10-08 14:02:21
150阅读
一 机器部署1、机器组成7台机器，均为16G内存 每台服务器均有4个CPU，2核 2、运行环境配置3、刷盘方式每台机器master机器均采用异步刷盘方式 二 性能评测1、评测目的 测试rocketmq是否存在消息堆积场景。 2、评测
转载
2024-06-17 13:35:46
164阅读
RocketMQ消息堆积问题RocketMQ消息堆积主要分为三个层次的问题：
其一是Producer生产速率过快，什么场景呢，比如Producer故障，比如DOS攻击，比如业务高峰（超过企业预估的，例如12306订票，双十一下单，这些一开始的时候都有超过预期的情况）。其二是Broker消息堆积，比如Broker的性能瓶颈，Broker同步策略导致消息堆积等其三是Consumer本身已经拉取消息的堆
转载
2023-10-28 14:11:45
14阅读
RocketMQ是一款分布式消息中间件，具有高性能、高可靠性、高规模扩展能力等特点，广泛应用于各种场景。不过，与其他中间件一样，RocketMQ在使用过程中可能会面临消息堆积的问题。要解决这个问题，可以采用以下策略。 调整消费者消费速度在遇到消息堆积时，首先需要判断是否是消费者消费速度过慢导致的问题。可以通过增加消费者线程数量、消费者并行度等方式来优化消费性能。特别对于某些具有复杂处理
引入RocketMQ会有哪些问题？重复消息问题消息生产者产生了重复的消息消息消费者确认失败
当消费失败的时候，mq可能会重新发送消息消息消费者确认超时
超时也会使mq重新发送消息业务系统主动发起重试解决方法：最重要的一点是 幂等性：可以使用自带的messageid做唯一索引，在数据库添加一个唯一索引，从数据库层面会报错，避免消息重复。mysql唯一索引保证表中字段唯一，若存在id则之前
问题现象今天忽然收到RocketMQ预警信息如下： 提醒有部分数据没有消费，产生堆积情况。打开RocketMq-Console-Ng查看如下图形式： 备注：第一反应是Consumer Group内订阅了多个topic？（为什么这么怀疑，下次分析）。通过命令statsAll 作用是查询Topic and Consumer tps stats：sh mqadmin statsAll -n na
转载
2024-06-28 10:45:48
324阅读
一、消息的幂等RocketMQ可以保证消息不丢失但是无法保证消息不重复。当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费过程就是消费幂等的。消费一次和消费多次对系统产生影响相同。 重复的消息可能会影响业务处理，需要做幂等处理。消息重复的场景 1）发送消息时消息重复：生产者向broker发送消息，broker网络
转载
2024-01-12 10:35:18
192阅读
其仅可以保证该Topic的每个Queue分区中的消息被顺序消费，不能保证整个Topic中消息的顺序
原创
2022-09-24 00:48:42
859阅读
一、技术背景在我们的日常项目中，Kafka是一项很常用的技术，我们可以用来做MySql + Cancel + Kafka实现数据库表的监听，实现具体的一些逻辑。同样Kafka也是一款高吞吐、高性能的消息中间件。具体的Kafka的技术相关事项就不在这里多做赘述。二、业务背景我这次的业务是基于某个一个订单在执行完业务逻辑后将执行完成的消息发送到Kafka，异步执行后置的逻辑。三、技术设计方案图由于具体
转载
2024-06-17 11:02:51
154阅读
一、消息队列解决的问题：引入消息队列一般能解决一下五种场景：异步处理，应用解耦，流量削锋，日志采集和消息通讯1、异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式（1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端（2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，
转载
2024-02-23 17:04:44
199阅读
磁盘重认识 当需要从磁盘读取数据时，要确定读的数据在哪个磁道，哪个扇区：首先必须找到柱面，即磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间;然后目标扇区旋转到磁头下,这个过程耗费的时间叫做旋转时间；一次访盘请求（读/写）完成过程由三个动作组成寻道（时间）：磁头移动定位到指定磁道;旋转延迟（时间）：等待指定扇区从磁头下旋转经过；数据传输（时间）：数据在磁盘、内存与网络之
转载
2024-06-18 14:17:54
61阅读
系统架构对比Kafka RocketMQ 数据存储Kafka一个topic后面分为多个partition，每个partition对应一个日志文件跟一个索引文件RocketMQ一个topic可分为多个ConsumeQueue，每个ConsumeQueue存储的是每个消息在commitlog这个文件的地址，但是消息存在于commitlog中数据可靠性RocketMQ支持异步实时刷盘
转载
2024-03-27 09:59:53
67阅读
一、使用RocketMQ如何保证消息不丢失？1 哪些环节会有丢消息的可能？这个是在面试时，关于MQ，面试官最喜欢问的问题。这个问题是所有MQ都需要面对的一个共性问题。大致的解决思路都是一致的，但是针对不同的MQ产品又有不同的解决方案。分析这个问题要从以下几个角度入手： 其中，1，2，4三个场景都是跨网络的，而跨网络就肯定会有丢消息的可能。然后关于3这个环节，通常MQ存盘时都会先写入操作系统的缓存p
转载
2024-10-05 10:11:41
100阅读
收到某业务组的小伙伴发来的反馈，具体问题如下：项目中某 kafka 消息组消费特别慢，有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。从服务端日志看到如下信息：该消费组在短时间内重平衡了 600 多次。从 cat 查看得知，每条消息处理都会有 4 次数据库的交互，经过一番沟通之后，发现每条消息的处理耗时大概率保持在 200ms 以上。Kafka 发生重平衡的有以下几种情况
转载
2024-03-27 17:15:24
186阅读
