Azure Service Bus + MassTransit消费者间歇性无法接收消息排查咨询

• 检查MassTransit消费者配置细节

  • 确认ConcurrencyLimit设置是否合理，即便发送消息量小，若并发限制过低且之前的消息处理卡住（比如隐性死锁、异步操作未正确await），会导致后续消息无法被拾取。
  • 验证UseMessageRetry或UseDelayedRedelivery的配置，若重试策略不当（如间隔过长、次数过多），可能导致消息被暂时锁定却未被正确处理。
  • 排查消费者注册是否正确，比如容器中注册的生命周期（单例/瞬态）是否符合预期，是否存在依赖注入失败的隐性问题（如依赖项未初始化，导致消费者实例创建失败但无异常抛出）。

• 排查Azure Service Bus队列的隐藏状态

  • 除了Active Messages和Dead-Lettered Messages，还要关注Scheduled Messages和Deferred Messages，确认消息是否被意外延迟或延期。
  • 检查队列的Lock Duration设置，如果消费者处理消息的时间超过锁时长且未主动续期，消息会回到活动队列，但MassTransit可能未正确重新拾取。可通过UseMessageLockRenewal配置确认是否启用了锁续期。
  • 确认队列是否开启了Session State，若启用但消费者未正确处理会话消息，会导致会话锁定，后续同会话的消息无法被处理。

• 启用MassTransit详细日志

  • 在应用中开启MassTransit的Debug级别日志，重点关注：
    • 消费者实例的创建与销毁日志，确认是否存在实例创建失败的情况。
    • 消息接收、锁定、处理、完成的全流程日志，查看是否有消息被拾取后未完成，或锁定超时的记录。
    • 与Azure Service Bus的连接日志，排查是否存在连接波动、重新连接的情况，导致临时无法接收消息。
  • .NET环境下的日志配置示例：

    services.AddMassTransit(x =>
    {
        // 消费者注册逻辑
        x.UsingAzureServiceBus((context, cfg) =>
        {
            cfg.ConfigureLogContext();
            // 其他Service Bus配置
        });
    });
    

    同时在appsettings.json中设置日志级别：

    "Logging": {
        "LogLevel": {
            "MassTransit": "Debug"
        }
    }
    

• 模拟场景复现问题

  • 在测试环境中复刻生产环境的负载、消息结构及依赖服务状态，尝试复现间歇性问题。
  • 给消费者处理逻辑添加内部详细日志（如进入/退出方法、关键步骤耗时），排查是否存在特定消息或场景导致处理卡住。
  • 检查消费者中的异步操作是否都正确使用await，避免线程挂起导致消费者实例无法处理后续消息。

• 分析Azure Service Bus运行时指标

  • 查看Azure Portal中Service Bus的指标：Server Errors、Client Errors、Message Lock Lost、Active Connections，这些指标可能包含诊断日志未捕获的异常信息。
  • 关注Message Count的变化趋势，确认消息滞留是持续发生还是偶发，是否与应用重启、部署时间点相关。

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