【Azure Service Bus】 Service Bus如何确保消息发送成功，发送端是否有Ack机制 

问题描述

Service Bus如何确保消息发送成功，发送端是否有Ack机制(是否有回调API告诉发送端，服务端已经收到消息)？根据对.NET发送Service Bus消息代码的分析，发送方法queueClient.SendAsync(message)并没有返回值，所以无法知道发送消息是否成功。

问题根源

Azure 服务总线已针对持久性进行优化，会确保在服务确认请求成功之前，发送到服务总线的所有数据将提交到存储。一旦服务总线成功“ACK”（确认）请求，即表示服务总线已成功处理该请求。 如果服务总线返回“NACK”（失败），则表示服务总线无法处理该请求，客户端应用程序必须重试该请求。官方提供的SDK，在没有自定义RetryPolicy的情况下，都会采用默认的重试机制。

Service Bus .Net SDK 默认的重试机制(RetryPolicy)为：

• DeltaBackoff: 重试之间的间隔时间
• MaxRetryCount: 最大重试次数
• MaximumBackoff: 最大的间隔时间
• MinimalBackoff: 最小的间隔时间

所以在调用Service Bus SDK发送消息时，如果代码正常执行且没有Exception，则表示消息成功发送。

一句话总结为：无错即成功，失败看异常。

另外也有如下两种发送俩查看消息：

方式一：在Azure Service Bus门户中查看指标 Incoming request/message

方式二：通过Servie Bus Explorer工具查看发送消息的内容

Service Bus异常消息类型

1. 用户代码错误（System.ArgumentException、System.InvalidOperationException、System.OperationCanceledException、System.Runtime.Serialization.SerializationException）。 常规操作：继续之前尝试修复代码。
2. 设置/配置错误（Microsoft.ServiceBus.Messaging.MessagingEntityNotFoundException、System.UnauthorizedAccessException）。 常规操作：检查配置，必要时进行更改。
3. 暂时性异常（Microsoft.ServiceBus.Messaging.MessagingException、Microsoft.ServiceBus.Messaging.ServerBusyException、Microsoft.ServiceBus.Messaging.MessagingCommunicationException）。 常规操作：重试操作或通知用户。 客户端 SDK 中的 RetryPolicy 类可以配置为自动处理重试。 有关详细信息，请参阅重试指南。
4. 其他异常（System.Transactions.TransactionException、System.TimeoutException、Microsoft.ServiceBus.Messaging.MessageLockLostException、Microsoft.ServiceBus.Messaging.SessionLockLostException）。 常规操作：特定于异常类型。

异常类型

下表列出了消息异常的类型及其原因，并说明可以采取的建议性操作。

异常类型

参考资料

Service Bus Explorer： https://github.com/paolosalvatori/ServiceBusExplorer/releases

Service Bus Retry Policy： https://docs.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific#service-bus