消息队列mq
关注
分享
扫一扫
文章平均质量分 85
埃泽漫笔
OceanBase开源项目ODC(OceanBase Developer Center)的核心贡献者，Github地址：https://github.com/oceanbase/odc，希望大家能赏脸支持下我们OceanBase公司的开源项目，点亮一颗小星星就行。
Maven中央仓库OceanBase开源组件 https://central.sonatype.com/artifact/com.oceanbase/db-browser 和 https://central.sonatype.com/artifact/com.oceanbase/ob-sql-parser 的核心贡献者。
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
Kafka、ActiveMQ、RabbitMQ、RocketMQ 对比
没有“最好”的消息队列，只有“最合适”的选择。Kafka 是高吞吐的王者，ActiveMQ 是中小场景的易用之选，RabbitMQ 擅长复杂路由，RocketMQ 则在性能、事务、扩展性之间做到了均衡。实际选型时，建议结合业务吞吐量、延迟要求、路由复杂度、团队技术栈四个维度综合评估，必要时可搭建原型进行压测验证。原创 2025-10-17 23:23:27 · 1214 阅读 · 0 评论 -
RocketMQ 事务消息
RocketMQ 事务消息通过“预备消息打底、本地事务执行、结果确认、回查兜底”的全流程设计，完美解决了分布式系统中“本地操作与消息发送原子性”问题。其核心是通过两阶段提交思想，结合持久化存储和定时回查，确保最终数据一致性。原创 2025-10-16 23:39:07 · 1113 阅读 · 0 评论 -
RocketMQ的负载均衡策略
若内置策略无法满足需求，RocketMQ 允许通过实现接口，自定义 Queue 分配逻辑。实现步骤实现接口，重写allocate方法，在方法中定义自己的分配规则（如按实例 IP Hash、按业务模块指定 Queue 等）。消费者初始化时，通过方法指定自定义策略。代码示例（自定义策略骨架）// 1. 实现自定义策略接口@Override// 自定义分配逻辑：例如按当前实例ID的Hash值分配Queue// 省略具体分配代码...@Override// 策略名称。原创 2025-10-16 22:08:43 · 672 阅读 · 0 评论 -
RocketMQ如何保证消息不丢失
在Broker层面，通过持久化机制（刷盘）来保证单机可靠性，通过主从复制机制来保证集群的高可用。生产上可以根据业务在性能和可靠性之间做权衡，比如选择同步刷盘还是异步刷盘。在生产端，我们依赖发送状态确认和内部重试机制，确保消息一定能成功送达Broker。在消费端，最关键的是采用手动ACK确认机制，只有在业务逻辑真正执行成功后，才告知Broker消息已消费。如果处理失败，Broker会通过重试机制重新投递，直到消费成功。通过这套‘刷盘 + 主从 + 确认 + 重试’原创 2025-10-15 23:26:31 · 1181 阅读 · 3 评论 -
RocketMQ的消费模式
大部分业务场景选集群模式，核心是 “负载均衡 + 避免重复处理”；少数需要 “全员处理” 的场景选广播模式，核心是 “消息群发 + 独立处理”。原创 2025-10-14 23:38:19 · 933 阅读 · 0 评论 -
RabbitMQ 消息可靠投递
机制解决问题优点缺点推荐场景发布者确认确保消息成功发送到 Broker性能高，非阻塞（异步模式），是 RabbitMQ 官方推荐的标准做法。需要额外的代码来处理确认逻辑。绝大多数场景下的首选。事务确保消息发送的原子性语义清晰，易于理解。性能极差，严重影响吞吐量。对性能要求不高，但对一致性要求极高的罕见场景。消费者手动 Ack确保消息被成功处理可靠性高，是保证消费端不丢消息的唯一标准做法。需要开发者手动管理 Ack 的发送时机，逻辑上要确保不遗漏。所有需要确保消息被可靠处理的场景，应始终开启。原创 2025-10-14 23:19:51 · 966 阅读 · 0 评论 -
Rabbitmq如何避免消息丢失
为了构建一个真正可靠的 RabbitMQ 系统，建议你组合使用以下方案：环节核心机制最佳实践生产端发布者确认 (Publisher Confirms)这是保证消息成功送达 MQ 服务器的首选方案，性能好且可靠。MQ 服务器端持久化 (Durability)必须开启。将队列（）和消息（）都设置为持久化，防止 MQ 重启丢失数据。消费端手动 Ack (Manual Acknowledgements)必须开启。将autoAck设置为false，在业务逻辑成功执行后，手动调用basicAck。原创 2025-10-13 23:04:15 · 803 阅读 · 0 评论 -
RabbitMQ为什么使用AMQP协议
特性解释带来的好处可靠性消息确认、持久化、发布确认保证数据不丢失，系统更稳定灵活性交换机、路由键、多种路由策略满足复杂的业务场景，解耦能力强跨平台多语言API支持技术栈无关，易于系统集成“RabbitMQ的核心是实现了AMQP协议，这让它具备了高可靠性、强大的路由灵活性和优秀的跨平台能力，成为了构建分布式系统的利器。原创 2025-10-13 22:32:53 · 977 阅读 · 0 评论 -
RabbitMQ四种交换机详解
大家好！在消息队列的世界里，RabbitMQ无疑是一个明星产品。今天我们要深入探讨的是RabbitMQ的核心——交换机（Exchange）。想象一下，交换机就像是邮局里的分拣员，负责把不同类型的邮件（消息）投递到正确的邮箱（队列）。掌握了交换机，你就掌握了RabbitMQ的精髓！简单来说，交换机就是消息的"交通指挥中心"。生产者发送消息到交换机，交换机根据类型和规则，决定把消息路由到哪些队列。RabbitMQ提供了四种不同类型的交换机，每种都有其独特的路由策略。交换机类型路由方式性能使用频率。原创 2025-10-12 23:31:37 · 1209 阅读 · 0 评论 -
RabbitMQ 核心概念解析
RabbitMQ 作为主流的开源消息队列，凭借高可靠性、灵活的路由策略，成为分布式系统解耦、削峰的常用工具。但很多新手刚接触时，会被“交换机”“信道”“虚拟主机”等概念绕晕，不清楚消息从生产者到消费者到底怎么流转。这篇文章用“概念拆解+消息流转图+实战案例”的方式，把 RabbitMQ 核心概念讲透，帮你快速入门。最后用一句口诀帮你记住核心逻辑：“生产者发消息给交换机，交换机按键绑队列，消费者从队列取消息，确认之后消息删”原创 2025-10-12 22:45:58 · 1515 阅读 · 0 评论 -
消息积压的问题如何解决
大家好，今天我们来聊聊一个让无数后端工程师“头秃”的问题——消息队列（MQ）积压。这是一个在高并发系统中非常常见且棘手的问题。如果处理不当，小则导致业务延迟，大则可能引发雪崩效应，让整个系统瘫痪。我将从**“紧急止血”和“长效根治”**两个角度，为你详细拆解如何应对这个问题。短期应急：通过增加消费者实例或使用临时程序转移消息，快速恢复系统的消费能力，防止问题扩大化。长期优化向内看：深入分析并优化消费者的处理逻辑，这是提升性能的关键。向外看：审视生产者，通过限流、降级。原创 2025-10-12 22:05:43 · 1117 阅读 · 0 评论 -
消息队列延迟与过期问题的实战解决
问题类型核心原因解决方案消息延迟消费慢、MQ瓶颈增加消费者、优化代码、调整分区、调参消息过期TTL不合理、消费堆积调整TTL、引入死信队列在实际项目中，这两类问题往往是交织的。解决它们不仅需要运维层面的调优，还需要开发人员对业务逻辑和MQ原理有深入理解。原创 2025-10-11 23:19:40 · 615 阅读 · 0 评论 -
死信队列vs延迟队列
大家好，今天我们来聊聊消息队列中两个很实用但经常被忽视的特性——死信队列和延迟队列。无论是在实际开发中，还是在技术面试中，理解这两个概念都能让你脱颖而出。简单来说，死信队列就是用来存放那些“处理不了”的消息的特殊队列。延迟队列就像是消息的“等候室”——消息发进去后，不会立即被消费，而是等设定的时间到了才会被投递出去。死信队列是你的安全网，确保问题消息不会影响正常业务流程延迟队列是你的定时器，让消息在正确的时间做正确的事。原创 2025-10-10 23:31:50 · 541 阅读 · 0 评论 -
MQ重复消费问题
简单说：同一条消息，消费1次和消费100次，结果一样。比如“扣库存”消息，重复消费后，库存也不会多扣。记住“1个核心+4个原因+1个方案”核心：MQ重复消费无法完全避免，因为重发是为了确保消息不丢失；原因：消费方没ack、位点提交失败、发送方逻辑错、网络不稳；解决办法：消费方做好幂等处理，常用“唯一ID防重”或“业务状态防重”。重复消费不是MQ的“bug”，而是为了“消息不丢失”付出的合理代价。只要消费方做好幂等，重复消费就不会影响业务——这是MQ开发的必备技能。原创 2025-10-09 23:49:47 · 911 阅读 · 0 评论 -
如何避免消息重复投递或重复消费
大家好，在消息队列的使用过程中，重复消费是一个比消息丢失更常见的问题。想象一下这样的场景：用户支付了100元，由于消息重复消费，账户被扣了200元；商品库存原本有100件，重复消费后变成了98件... 这种问题如果处理不好，会给业务带来严重的影响。今天我们就来深入探讨消息重复消费的原因，以及如何通过幂等性设计来彻底解决这个问题。原创 2025-10-08 23:26:50 · 581 阅读 · 0 评论 -
如何避免消息丢失
大家好，在消息队列的使用过程中，消息丢失是一个让很多开发者头疼的问题。特别是在金融、电商等对数据一致性要求极高的场景中，消息丢失可能意味着资金损失、订单异常等严重问题。今天我们就来深入剖析消息丢失的各个环节，并提供从生产到消费的完整防护方案。生产端：使用确认机制 + 重试 + 异步回调服务端：配置持久化 + 副本同步 + 定期备份消费端：手动提交 + 异常处理 + 死信队列监控：实时监控 + 告警通知 + 日志追踪防止消息丢失是一个系统工程，需要在消息的整个生命周期中都做好防护。原创 2025-10-07 23:52:36 · 814 阅读 · 0 评论 -
消息顺序消费问题
大家好，在消息队列的使用过程中，顺序消费问题是一个经常被提及的难点。特别是在面试中，这个问题出现的频率相当高。今天我们就来深入探讨一下消息顺序消费的问题，分析其原因并提供实用的解决方案。先来看一个简单的业务场景：假设我们有一个订单状态更新的需求，需要先执行"新增订单"操作，再执行"删除订单"操作。如果这两条消息的处理顺序颠倒，先执行了删除再执行新增，就会导致业务逻辑错误，这就是典型的消息顺序消费问题。原创 2025-10-06 23:24:12 · 1120 阅读 · 0 评论 -
mq的常见问题
消息不丢：发送方要确认、MQ要持久化、消费方要手动ack；消息不重：业务要做幂等，用唯一ID或状态机防重；顺序不乱：单线程消费或按关键字段分区；不积压：监控报警+临时扩容+优化消费速度。其实MQ的问题都有固定解法，关键是要在上线前做好预案，别等线上出问题了再慌慌张张处理。希望这篇文章能帮你避开MQ的坑，让线上系统更稳定！原创 2025-10-05 23:39:24 · 1525 阅读 · 0 评论 -
引入消息队列的缺点
很多开发同学刚开始使用消息队列（MQ）时，往往只看到它能解耦系统、削峰填谷的优点，觉得简直太爽了。但等到真正上线后才发现：消息丢了、重复消费导致数据错乱、系统复杂度直线上升...实际上，MQ 在解决问题的同时，也会引入新的麻烦。本文将深入剖析 MQ 的 6 个真实痛点，每个痛点都配有业务实例和避坑方案，帮助你在使用 MQ 前做好充分准备。不是必须用，就不用：如果系统没有遇到解耦、削峰等实际问题，不要为了"炫技"而使用 MQ，简单的同步调用比复杂的异步交互更稳定不做好避坑方案，不用。原创 2025-10-05 23:29:32 · 735 阅读 · 0 评论 -
为什么要使用MQ
核心价值：MQ主要解决分布式系统的“解耦”和“削峰”问题，同时支持异步处理和可靠投递；场景举例解耦：下单后通知、送券、加积分，用MQ让服务互不依赖；削峰：秒杀场景用MQ存请求，避免冲击数据库；避坑意识：不是所有场景都能用，比如实时性要求极高的场景，得选其他方案。MQ不是“高大上的炫技工具”，而是解决实际问题的“刚需”。什么时候该用？就看你有没有遇到“服务耦合死”“峰值扛不住”这些痛点——有痛点，MQ就是救星；没痛点，强行上MQ就是给自己找麻烦。原创 2025-10-04 23:29:07 · 1005 阅读 · 0 评论 -
MQ 的使用场景
核心价值：MQ解决了分布式系统的“异步、解耦、削峰”问题，提升系统响应速度、扩展性和稳定性；重点场景：结合1-2个你项目里的实际场景，比如“我们项目在秒杀场景用MQ削峰，把10万QPS的峰值拉平到1000QPS，避免数据库崩溃”；避坑意识：提一句“不是所有场景都用MQ，比如实时性要求极高的场景，我们会用其他方案”，显得你考虑周全。MQ不是“银弹”，它的价值在于“解决特定场景的问题”。实际工作中，先想清楚“不用MQ会有什么问题”，再决定要不要上——这才是正确的使用姿势，而不是为了“用MQ而用MQ”。原创 2025-10-04 23:16:33 · 1117 阅读 · 0 评论