gpt4 book ai didi

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

转载 作者:太空宇宙 更新时间:2023-11-03 21:02:25 26 4
gpt4 key购买 nike

我使用 azure 服务总线主题作为我的解决方案的消息代理。根据我对每个订阅的理解,Azure 消息总线保留一个虚拟队列,因此在接收消息的最终顺序时不应受到干扰。

但实际上在我的场景中有点不同

  • 大约每两秒输入一次,(时间戳正确,我已验证)
  • 如果我断开接收器一段时间,消息就会开始在 Azure 上针对订阅排队。
  • 那么如果我再次连接接收者,接收代码会很快接收消息,但顺序不保持?
  • 但是,如果我保持客户端连接,则会按顺序接收消息(两秒后收到一条消息)

接收代码

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

谁能解释一下为什么会这样吗?这对我来说有点困惑?

最佳答案

虽然 Azure 服务总线将自身提供为 FIFO(先进先出),但这仅在不间断 session 期间真正起作用。正如您所经历的:

However If I keep the client connected, the messages are received in order

要解决此问题,您可以使用不同的模式。请在下面的链接中查看 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

下面是该文档的引用,它指定您需要使用消息传递 session 才能获得 FIFO。

The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. In the event that the application crashes while processing a message received in the Peek & Lock mode, the next time a queue receiver accepts a messaging session, it will start with the failed message after its time-to-live (TTL) period expires.

关于实现消息 session 的文档似乎相当缺乏,但根据我的理解,它来自 MessageSession 类,并且它是 AcceptMessageSession 方法

关于c# - Azure 服务总线主题订阅者接收订单,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44136875/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com