当前位置:首页 >专题 >Go RabbitMQ 消息队列实战专题
Go RabbitMQ 消息队列实战专题
官方入口与开发资料
先核对 RabbitMQ 4.x、AMQP、Go 客户端和可靠性文档
RabbitMQ 官方网站
RabbitMQ 官方入口,覆盖产品介绍、下载、文档、社区和版本信息。
RabbitMQ 官方教程总览
官方教程总览,覆盖 AMQP 1.0、AMQP 0-9-1、队列和 Streams,并提供 Go 示例。
RabbitMQ Go Hello World
RabbitMQ 官方 Go 入门,演示 amqp091-go 连接、声明队列、发布与消费。
RabbitMQ 使用指南
官方开发者指南,覆盖交换机、队列、发布、消费、Streams、客户端和插件。
RabbitMQ 可靠性与数据安全
官方可靠性文档,说明确认、持久化、复制、故障恢复和数据安全边界。
RabbitMQ 监控文档
官方监控指南,覆盖队列、连接、通道、节点和 Prometheus 指标。
rabbitmq/amqp091-go 官方仓库
RabbitMQ Go AMQP 0-9-1 客户端源码、示例、版本和问题追踪入口。
amqp091-go API 文档
Go 客户端 API 参考,覆盖 Connection、Channel、Publish、Consume、Confirm 和 Notify。
RabbitMQ 消息队列常见问题
围绕确认、重连、并发与积压的实用答案
RabbitMQ 的 exchange、queue 和 routing key 如何配合?
生产者把消息发布到 exchange,exchange 根据 binding 和 routing key 将消息路由到一个或多个 queue,消费者只从 queue 获取消息;queue 才是消息等待消费和进行 ack 的位置。
RabbitMQ 怎样减少消息丢失和重复消费?
生产端使用 publisher confirms,消息和队列按业务需要持久化;消费端使用手动 ack,并在业务成功后确认。网络重试和消费者重启仍可能造成重复,因此必须用业务幂等键、重试队列或死信处理重复与失败。
Go RabbitMQ 客户端应该复用 connection 和 channel 吗?
通常应复用长期 connection,并按并发模型管理 channel;不要为每条消息反复 Dial。channel 不是任意并发场景下都可以无约束共享,发布确认、消费和关闭都应配合客户端文档设计生命周期。
RabbitMQ 消费积压时应该先扩容还是先排查?
先确认队列增长速度、消费者处理耗时、prefetch、下游限流、连接状态和节点资源,再判断是否安全增加消费者;盲目扩容可能放大数据库或外部 API 压力,还要关注消息顺序、重试和死信。
相关专题
继续查看相近方向内容
-
- Go 配置热加载为什么偶发读到旧值:JSON 复用、零值覆盖与原子替换
- 2分钟前 311浏览
-
- MySQL 8.0 SKIP LOCKED 怎么做任务抢占:锁范围、空队列与重复消费验收
- 10分钟前 228浏览
-
- Go 接 Ollama API 做模型健康检查:版本、模型存在性与超时处理
- 32分钟前 216浏览
-
- Go 回调地址怎么做 SSRF 防护:域名白名单、解析结果与跳转控制
- 42分钟前 116浏览
-
- Go 1.24 os.Root 如何限制文件系统越界:路径校验、符号链接与兼容边界
- 1小时前 437浏览

