Azure Service Bus隔次发送消息异常问题如何排查解决？

问题原因排查与结论 #

首先排除限流规则影响 #

Azure Service Bus的限流触发时会明确返回429状态码，同时抛出ServerBusyException类异常，你的异常处理程序全程未触发、且日发送量仅300条远低于各定价层的阈值，因此该现象与限流无关。

大概率触发原因（完全符合你反馈的表现特征） #

该问题是旧Service Bus命名空间/队列的配置异常或底层实例故障导致，与你的代码逻辑无关，核心可能性按优先级排序如下：

• 旧队列开启了重复检测功能，且你未在自定义的SendMigrationMessageAsync方法中显式设置唯一的MessageId，旧版Service Bus SDK在批量发送小体积消息时，有可能生成重复的默认MessageId，服务端会静默丢弃被判定为重复的消息，不会返回任何错误，完全符合你隔次发送失败、无异常抛出的表现。
• 旧命名空间下存在其他未下线的活跃接收端，该接收端使用ReceiveAndDelete模式消费消息，会和你的桌面端抢消费，因此你只能收到一半的消息，发送单条消息时直接被其他接收端拉走，自然看不到消息出现在队列中。
• 旧队列配置了自动转发规则，消息发送后被自动转发到其他队列/主题，不会留在当前队列供你消费。
• 早期创建的Basic层分区队列出现了底层分区节点异常，部分分片写入失败但未向上抛出错误，这类底层故障重建命名空间即可自动恢复，也符合你新建命名空间后问题消失的表现。

旧队列定位问题方案 #

如果需要排查旧队列的具体问题，可以按以下步骤操作：

1. 进入Azure门户旧Service Bus队列的配置页，检查重复检测、自动转发、会话等配置是否和新队列一致
2. 查看旧队列的消息指标，确认消息发送成功数、传入消息数、传出消息数的统计值，判断是发送阶段丢失还是发送后被其他消费者消费
3. 检查旧命名空间的访问策略，是否存在其他应用使用的密钥仍在活跃调用

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