NServiceBus 6.0.0.0+AzureStorageQueueTransport消息无异常丢失问题求助

我之前在处理高吞吐量消息场景时，也碰到过类似Azure存储队列结合NServiceBus丢消息的情况，结合你描述的0.01%消息悄无声息消失的问题，给你梳理几个实用的排查方向和解决方案：

1. 先查最容易忽略的死信队列 #

Azure存储队列会把不符合规则的消息移到死信队列，但很多时候我们会忘记检查这个地方。比如：

• 消息序列化后大小超过Azure队列的64KB限制
• 消息的TTL（存活时间）到期未被处理
• 发送时遇到重复的消息ID冲突（某些场景下）

你可以直接在Azure门户找到对应的队列，查看它的死信队列（命名格式是原队列名-deadletter），或者用Azure CLI命令快速查看：

az storage message peek --queue-name <your-queue-name>-deadletter --account-name <your-storage-account>

如果死信队列里有丢失的消息，就能直接定位原因。

2. 启用NServiceBus的详细日志，抓被吞的异常 #

旧版本的AzureStorageQueueTransport可能存在静默吞掉异常的情况——消息发送失败但没抛出异常，也没记录日志。你可以把NServiceBus的日志级别调到Trace或者Debug，重点关注NServiceBus.Transports.AzureStorageQueues相关的日志条目：

在端点配置里添加日志配置（以Serilog为例）：

Log.Logger = new LoggerConfiguration()
    .MinimumLevel.Trace()
    .WriteTo.Console()
    .CreateLogger();

endpointConfiguration.UseSerilog();

发送消息时，仔细看日志里有没有发送失败的痕迹，比如网络超时、Azure存储返回的4xx/5xx错误，这些可能是消息丢失的根源。

3. 检查NServiceBus的发送重试与错误队列配置 #

默认情况下，NServiceBus可能对发送失败的处理不够激进，或者没有配置错误队列导致消息直接丢失。你可以确认以下配置：

• 确保错误队列已配置，失败的消息会被移到错误队列而非消失：

  endpointConfiguration.SendFailedMessagesTo("error-queue");
  

• 调整Azure传输的重试策略，应对网络瞬态错误：

  var transport = endpointConfiguration.UseTransport<AzureStorageQueueTransport>();
  // 自定义重试策略，比如重试5次，每次间隔1秒
  transport.RetryPolicy((exception, retryCount) => 
      retryCount < 5 ? TimeSpan.FromSeconds(1) : TimeSpan.MaxValue);
  

4. 监控Azure存储账户的吞吐量限制 #

当消息量巨大时，很容易触发Azure存储队列的吞吐量配额（默认是每秒最多2000个操作）。如果超出配额，Azure会返回429错误，旧版本的传输可能没有正确处理这个错误，导致消息丢失。

你可以在Azure门户的存储账户监控里查看：

• Transactions指标：看有没有突增到配额上限的情况
• Server Errors指标：有没有429/500级别的错误
  如果是配额问题，可以考虑拆分队列，或者申请提高存储账户的吞吐量配额。

5. 验证消息发送前的完整性 #

为了确认消息确实是发送后丢失，而不是序列化环节出问题，你可以在发送前做个简单的记录：

• 给每个消息生成唯一ID，发送前把ID和消息内容的哈希值写入本地日志或数据库
• 定期对比队列中的消息ID和本地记录的ID，统计丢失的消息数量和特征
  这样能帮你定位是特定类型的消息丢失，还是随机的传输问题。

6. 升级Azure存储队列传输版本 #

NServiceBus 6.0.0对应的AzureStorageQueueTransport版本比较旧（大概是2.x系列），后续版本修复了不少关于消息丢失的bug，比如优化了网络错误处理、死信逻辑等。你可以升级到兼容NServiceBus 6的最新传输版本（比如3.x系列），很多时候升级就能解决这类偶发的丢消息问题。

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