Azure服务总线主题订阅者接收订单

我正在使用azure服务总线主题作为我的解决方案的消息代理。根据我对每个订阅的理解，Azure消息总线保持虚拟队列，所以在接收端的消息顺序不应受到干扰。Azure服务总线主题订阅者接收订单

但在现实中却是有点不同，我的方案

输入大致每两秒钟后，（时间戳是正确的，我已经验证它）
如果我断开了一段时间的接收器，消息开始在Azure上针对订阅进行排队。
那么如果我再次连接接收器，接收代码很快就会收到消息，但是订单不会被保留？
然而如果予保持连接的客户，消息，以便接收（两秒后1个消息）

接收代码

SubscriptionClient Client = SubscriptionClient.CreateFromConnectionString(connectionString, topicname, subscription_name); 

       // Configure the callback options. 
       OnMessageOptions options = new OnMessageOptions(); 
       options.AutoComplete = false; 
       options.AutoRenewTimeout = TimeSpan.FromMinutes(1); 

       // Callback to handle received messages. 
       Client.OnMessage((message) => 
       { 
        try 
        { 
         // Process message from queue. 
         string payload = message.GetBody<string>(); 
         var myData = JsonConvert.DeserializeObject<MyData>(payload); 
         if(myData != null) 
         { 

          //Timestamp is not in order, when I connect after few minutes 
          Debug.WriteLine("SBC ==> " + myData.Timestamp); 

         } 
         // Remove message from queue. 
         message.Complete(); 
        } 
        catch (Exception) 
        { 
         // Indicates a problem, unlock message in queue. 
         message.Abandon(); 
        } 
       }, options);

输出

SBC ==> 5/23/2017 1:06:43 PM 
SBC ==> 5/23/2017 1:06:45 PM 
SBC ==> 5/23/2017 1:07:23 PM 
SBC ==> 5/23/2017 1:07:19 PM 
SBC ==> 5/23/2017 1:07:27 PM 
SBC ==> 5/23/2017 1:07:07 PM 
SBC ==> 5/23/2017 1:06:49 PM 
SBC ==> 5/23/2017 1:07:47 PM 
SBC ==> 5/23/2017 1:06:47 PM 
SBC ==> 5/23/2017 1:08:03 PM 
SBC ==> 5/23/2017 1:06:55 PM 
SBC ==> 5/23/2017 1:06:51 PM 
SBC ==> 5/23/2017 1:07:03 PM 
SBC ==> 5/23/2017 1:07:51 PM 
SBC ==> 5/23/2017 1:06:57 PM 
SBC ==> 5/23/2017 1:07:05 PM 
SBC ==> 5/23/2017 1:07:39 PM 
SBC ==> 5/23/2017 1:07:43 PM 
SBC ==> 5/23/2017 1:06:59 PM 
SBC ==> 5/23/2017 1:07:09 PM 
SBC ==> 5/23/2017 1:06:53 PM 
SBC ==> 5/23/2017 1:07:33 PM 
SBC ==> 5/23/2017 1:07:25 PM 
SBC ==> 5/23/2017 1:07:57 PM 
SBC ==> 5/23/2017 1:08:13 PM

任何人都可以解释为什么是这样吗？这对我有点困惑？

来源

2017-05-23 Muhammad Ummar

虽然天蓝色的服务总线将自身定义为FIFO（先进先出），但只有在不间断的会话期间才有效。当你与经历：

但是如果我保持连接的客户端，邮件，以便

要解决这个问题，你可以用不同的方式接收。在下面的链接中查看ReceiveAndDelete和PeekLock模式。

Service Bus Docs

这里有一些相关的堆栈溢出的职位，可以帮助您。

How to accomplish FIFO with Azure service bus topics

How to gurantee azure queue FIFO

编辑

This link contains some details on the FIFO

下面是从该文件，指定你需要为了得到FIFO使用消息会话的报价。

服务总线队列中保证的FIFO模式需要使用消息传递会话。如果应用程序在处理Peek &锁定模式下收到的消息时崩溃，则在队列接收器下一次接受消息传递会话时，它将在其生存时间（TTL）期限过期后开始发送失败消息。

文件似乎相当缺乏关于执行消息会话但是从我的理解是从MessageSession类，以及它的AcceptMessageSession方法

来源

2017-05-23 14:24:03 NPhillips

感谢您的意见，请您参考MSDN上的一些文档，其中“您遇到的问题是，当您断开接收器时，超时的消息会在一段时间后开始重试。这会导致他们失去他们发送的订单.'描述？这将是非常有帮助的。 –

将添加到答案。 – NPhillips

已经删除了从问题中引用的部分，因为无法为其提供可靠来源。前一段时间我遇到过这个问题，那是我对这个问题的理解，但是我的话当然很重要，因为没有文档可以支持它。您可能会觉得这篇博文有用，但我怀疑它有点过时了： http://www.ben-morris.com/dont-assume-message-ordering-in-azure-service-bus/ – NPhillips

就像@NPhillips说，你需要使用的邮件会话功能ASB实现FIFO行为。这意味着几件事情，这是必须注意的：

接收器将只处理一个单个会话的时间
并行处理是不可能的，你会下降到每一次的任何一个消息它需要处理。
发件人需要为每个邮件分配会话ID。

最好的样本和解释将由ASB团队发布在GitHub here上。

来源

2017-05-23 15:22:07

Azure服务总线主题订阅者接收订单

回答

相关问题