c#如何使用RabbitMQ_c#RabbitMQ新手必看入门教程

C#开发RabbitMQ：从基础连接到生产级实践的避坑指南

当你准备在C#项目中集成RabbitMQ时，有件事必须明确：RabbitMQ.Client是那个唯一必须引用的NuGet包。没错，市面上确实有各种封装库，比如EasyNetQ，它们用起来可能更“顺手”。但问题恰恰出在这里——这些高级封装往往会掩盖底层的核心行为。对于新手而言，一旦遇到连接异常、消息离奇丢失或者确认机制失效，很容易陷入完全抓瞎的境地，因为你根本不知道底层发生了什么。所以，从最基础的客户端库开始，是建立可靠认知的第一步。

安装 RabbitMQ.Client 并验证基础连接

千万别跳过本地服务验证这一步。经验表明，很多让人头疼的“连不上”问题，根源往往不是代码写错了，而是RabbitMQ服务本身压根就没跑起来。

• 服务状态是第一道关：在Linux上，用sudo service rabbitmq-server status检查；在Windows上，则去服务管理器里确认RabbitMQ服务的运行状态。
• 安装命令：通过Package Manager Console执行 Install-Package RabbitMQ.Client。
• 连接代码要显式：即使连接本地默认配置，也强烈建议在ConnectionFactory里显式写出HostName、Port、UserName、Password。依赖隐式默认值，会给未来部署到不同环境埋下隐患。
• 读懂错误信息：如果遇到System.IO.IOException: Unable to read data from the transport connection这类错误，通常指向两个方向：要么是端口（默认5672）被防火墙拦截，要么是用户权限不足（例如，默认的guest用户仅允许从localhost登录）。

声明 Queue 和 Exchange 时必须设对 durable 和 autoDelete

这两个布尔参数，直接决定了消息和队列的生命周期。新手常在这里栽跟头，设反了会导致消息在断电后丢失，或者应用重启后队列自动消失，让人措手不及。

• durable = true：这表示队列元数据本身会被持久化到磁盘。但请注意，这不等于消息内容自动持久化。要让消息也扛得住重启，必须单独设置消息的IBasicProperties.DeliveryMode = 2。
• autoDelete = false：这个设置意味着，即使所有消费者都断开连接，队列也不会被自动删除。如果把它设为true，就要小心了：一旦生产者发完消息而暂时没有消费者，队列会被立刻删除，导致消息永久丢失。
• Exchange同样需要持久化：声明Exchange时也必须配置durable: true。否则，RabbitMQ服务重启后Exchange会消失，生产者再发消息就会直接报错：404 NOT_FOUND - no exchange 'xxx'。
• 一个推荐的组合：QueueDeclare("log_queue", durable: true, exclusive: false, autoDelete: false, arguments: null)。这套配置兼顾了可靠性和可控性。

发送消息必须用 channel.ConfirmSelect() + channel.WaitForConfirmsOrDie()

这里有个关键认知：默认情况下，C#客户端发送消息是“发完即忘”模式。如果网络突然中断、Broker崩溃或者磁盘写满，生产者是收不到任何失败通知的。不加发布确认机制，无异于在线上“裸奔”。

• 调用顺序不能错：channel.ConfirmSelect()必须在channel.BasicPublish()之前调用。如果顺序颠倒，后续的WaitForConfirmsOrDie()会一直阻塞或直接抛出异常。
• 同步与异步的选择：WaitForConfirmsOrDie()是同步等待，适用于低频但至关重要的消息场景。如果是高频发送，则应改用异步回调模式：channel.BasicAcks += (sender, ea) => { ... }，以避免线程阻塞。
• 异常必须处理：如果未能收到Broker的确认，WaitForConfirmsOrDie()会抛出OperationInterruptedException
• 注意作用域：ConfirmSelect只对当前Channel生效。每个新建的Channel，如果需要确认，都必须重新启用这个模式。