如果你想把一条消息暂时放一放，并且你有地方写下SequenceNumber（它可能在会话队列的Session状态中），你可以使用Defer（）方法。这也是除了它们过期之外再次访问它们的唯一方法，所以要小心。这个特性是为工作流和状态机构建的，这样它们就可以处理无序的消息到达。

在上述第2项中：当调用Receive(TimeSpan)而不是默认的Receive()时，您不能只在消息上设置TTL时间跨度吗？然后，您可以简单地放弃该消息（不调用Abandon()），并且当TTL过期时，消息应该重新出现在队列中。“它确实可以给予你预测消息何时再次出现。”
注意：使用基于存储的队列，您可以更新不可见性超时，以便 * 将 * 为您提供对消息重新出现的细粒度控制。

感觉有点古怪，但我想到的解决办法是

try 
{
   ...
}
catch (Exception ex)
{
   await Task.Delay(30000);
   throw;
}

这样，它将等待30秒钟，然后才允许它放弃。它最终将死信后，配置的次数。
我正在使用Azure Webjobs进行接收。虽然我使用的是Task.Delay而不是Thread.Sleep，但它似乎没有释放线程来处理队列中等待的另一个项目（默认情况下，Webjobs并行处理16个项目）。

如果我是你，我会参考互联网上的Enterprise integration patterns页面中的一个来寻找解决方案。基本上，你想进行一次重试，如果失败，就将消息连续发送到一个死信队列。这些消息可以在以后重新排队。这可以根据需要手动或自动进行。
请注意，虽然我发送给你的页面与camel相关，因此该页面上描述的所有Java都适用于.NET和azure。如果你感兴趣，这里有一个更.NET的http://www.eaipatterns.com/

我更喜欢最后一种方法，因为它似乎是使用Azure服务总线的内置特性的最简单的解决方案。
流程如下：

var newMessage = new BrokeredMessage();
// Copy message body and properties from original message...

var scheduleTimeUtc = DateTimeOffset.UtcNow.Add(...);
await queueClient.ScheduleMessageAsync(newMessage, scheduleTimeUtc);

await originalMessage.CompleteAsync()

消息重新排队解决方案有一个问题（尽管这似乎是目前为止最好的解决方案）。这在主题/多订阅者模型中不会有效地工作，因为即使其他订阅者成功处理了新消息，它们也会将新消息传递给这些订阅者。
为了跟踪原始消息ID和正确的传递计数，可以在新消息中使用Message.UserProperties。