RabbitMQ C#客户端首次消息未确认，二次才拦截的问题排查

可能原因1：队列启用autoDelete属性，首次消息因无消费者被自动删除 #

若第三方应用创建队列时设置了autoDelete: true，当服务启动后消费者仍在重试连接（比如队列/交换机尚未存在），第三方发送的第一条消息会临时创建队列，但由于此时无消费者维持连接，RabbitMQ会自动删除队列，消息随之丢失。当消费者成功建立监听后，第三方发送第二条消息时，队列被重新创建并被监听，消息正常被接收。

解决方案 #

• 要求第三方将队列配置为非自动删除（autoDelete: false）并开启持久化（durable: true），确保队列在无消费者时仍保留。
• 修改本地ConfigureQueue方法，主动声明队列替代被动检查，确保服务启动时就创建好队列：

private void ConfigureQueue(string queueName, IModel model)
{
    // 主动声明持久化交换机
    model.ExchangeDeclare(exchange: "app.topicfan", type: ExchangeType.Topic, durable: true);
    // 主动声明持久化、非自动删除的队列
    model.QueueDeclare(queue: queueName, durable: true, exclusive: false, autoDelete: false, arguments: null);
    // 绑定队列到交换机（需与第三方确认路由键规则）
    model.QueueBind(queue: queueName, exchange: "app.topicfan", routingKey: "thirdparty.message.route");
    
    model.BasicQos(0, 250, true);
    _logger.LogWarning("Queue message count: " + model.MessageCount(queueName).ToString());
}

可能原因2：消费者初始化依赖被动声明，首次监听延迟 #

代码中ConfigureQueue使用QueueDeclarePassive和ExchangeDeclarePassive，这两个方法仅在队列/交换机已存在时才会成功，否则抛出异常进入重试逻辑。若第三方发送第一条消息时，消费者仍在重试，消息可能因队列属性（如自动删除）丢失，或因消费者未就绪无法被投递。

解决方案 #

• 替换被动声明为主动声明：用ExchangeDeclare和QueueDeclare替代被动检查，确保服务启动时就创建好所需资源，无需依赖第三方先发消息。
• 调整ConfigureQueue方法顺序，先声明资源再执行其他操作，避免因队列不存在触发异常：

private void ConfigureQueue(string queueName, IModel model)
{
    // 先完成交换机、队列声明与绑定
    model.ExchangeDeclare(exchange: "app.topicfan", type: ExchangeType.Topic, durable: true);
    model.QueueDeclare(queue: queueName, durable: true, exclusive: false, autoDelete: false, arguments: null);
    model.QueueBind(queue: queueName, exchange: "app.topicfan", routingKey: "thirdparty.message.route");
    
    // 再设置QoS和获取消息计数
    model.BasicQos(0, 250, true);
    _logger.LogWarning("Queue message count: " + model.MessageCount(queueName).ToString());
}

可能原因3：异步事件处理的async void风险 #

EventingBasicConsumer的Received事件使用async void委托，虽代码捕获了异常，但仍可能出现异步上下文丢失、消息确认时机紊乱的问题，极端情况下会导致消息未被确认或丢失。

解决方案 #

• 使用AsyncEventingBasicConsumer（需RabbitMQ.Client版本支持）替代EventingBasicConsumer，专门适配异步消息处理，规避async void的潜在问题：

// 替换为AsyncEventingBasicConsumer
var consumer = new AsyncEventingBasicConsumer(_model);
consumer.Received += async (sender, @event) =>
{
    try
    {
        var body = @event.Body.ToArray();
        var message = Encoding.UTF8.GetString(body);
        if (!string.IsNullOrWhiteSpace(message))
        {    
            await onMessageReceivedAsync?.Invoke(message);
            _model.BasicAck(@event.DeliveryTag, false); 
        }
    }
    catch (Exception ex)
    {
       _logger.LogError($"Error processing message: {ex.Message}");
       _model.BasicNack(@event.DeliveryTag, false, true);
    }
};

可能原因4：队列与交换机未绑定或路由键不匹配 #

若第三方消息发送到app.topicfan交换机，但你的队列未与该交换机绑定，或绑定的routingKey与第三方发送的规则不匹配，会导致消息无法进入队列。首次发送时绑定可能未完成，第二次发送时绑定生效，消息正常被接收。

解决方案 #

• 在ConfigureQueue中添加明确的绑定逻辑，确保队列与交换机的路由规则匹配：

// 根据第三方提供的路由规则调整routingKey
model.QueueBind(queue: queueName, exchange: "app.topicfan", routingKey: "thirdparty.#");

• 与第三方确认消息的routingKey格式，保证绑定规则能正确匹配消息。

内容的提问来源于stack exchange，提问作者Shyn