使用MaxDeliveryCount Azure ServiceBus消息进行重新处理

我试图使用ServiceBus订阅的MaxDeliveryCount来实现消息处理的重试。不确定这是最好的主意，但不想丢失消息。使用MaxDeliveryCount Azure ServiceBus消息进行重新处理

场景：

有一个主题，与两个订户一个发送（A）和其他（B）接收消息，使用皮克锁
两个订阅已经配置MaxDeliveryCount = 10
两个客户机使用 SubscriptionClient.ReceiveBatch（50，TimeSpan.FromMilliseconds（50））到从队列
甲获得消息发送5个消息，具有有效载荷 “1”， “2”，... “5”
第一消息（“1”）未能在乙处理和其放弃的被标记（BrokeredMessage.Abandon（））

原因：内部原因，应用程序无法处理现在该消息。

它没有因为DeliveryCount < MaxDeliveryCount）
下一页BlackLettered，因为“1”以前失败的消息时，只有一个消息是距离要求，并且它预计将信息“1” SubscriptionClient.ReceiveBatch（ 1，TimeSpan.FromMilliseconds（50））
经过2-3次重复的步骤7，代替接收消息“1”，接收到消息“2” 消息“2”也被标记为放弃，因为消息“1 “预计
然后收到消息“3”
由于消息“1”为，因此消息“3”也被标记为废弃

等等。

看来，在这种情况下，SB以循环方式发送消息。

这是ServiceBus的预期行为吗？

我知道SB是否保证有序交付，是否存在一些争议。对于应用程序来说，按照发送顺序处理消息非常重要。

任何想法如何处理消息“2”之前可以执行消息“1”的重新处理，直到DeliveryCount达到MaxDeliveryCount之前？

看来，这种行为与预取有关！ https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements：“如果客户端启动接收操作并且缓存中包含消息，则会发送消息从缓存中。“ –

你见过这篇文章：http://stackoverflow.com/questions/28702033/how-to-accomplish-fifo-with-azure-service-bus-topics？ – Thomas

有没有更新？你解决了这个问题吗？ –

首先，正如Thomas在他的评论中分享的那样，您可以尝试指定SupportOrdering property至true作为主题。

TopicDescription td = new TopicDescription("TopicTest"); 
td.SupportOrdering = true;

如果订阅客户端收到一条消息，并调用Abandon方法放弃上偷看锁定的消息锁，我们可以再次调用Receive方法再次得到它，就像这样。

输出：

在另一方面，如果可能的话，你可以尝试一个完整的工作步骤以特定的顺序在单消息结合起来，而不是在多个消息中拆分步骤，然后您可以在代码逻辑中按特定顺序控制处理，而不是在服务总线基础结构上回复以提供此保证即

2017-05-10 09:03:06

Fred，我会再次检查supportOrdering选项。我记得我已经设置这是真实的，但问题没有解决。 –

回答