0

我有一个 Azure 服务总线命名空间，包含 8 个主题，每个主题至少有一个订阅。

通常有两个逻辑应用，第一个每半小时（在 15 点和 45 点）从我们的数据库中提取数据并将其放置到选择的服务总线主题上，第二个使用“收到消息时触发”在主题订阅中（自动完成）”触发连接器 - 具有默认并发设置 (25)。一个例子如下所示

"When_a_message_is_received_in_a_topic_subscription_(auto-complete)": {
            "conditions": [],
            "inputs": {
                "host": {
                    "connection": {
                        "name": "@parameters('$connections')['servicebus']['connectionId']"
                    }
                },
                "method": "get",
                "path": "/@{encodeURIComponent(encodeURIComponent('exampletopic'))}/subscriptions/@{encodeURIComponent('examplesubscription')}/messages/head",
                "queries": {
                    "subscriptionType": "Main"
                }
            },
            "recurrence": {
                "frequency": "Minute",
                "interval": 30,
                "startTime": "2021-01-27T00:00:00.000Z",
                "timeZone": "UTC"
            },
            "runtimeConfiguration": {
                "concurrency": {
                    "runs": 25
                }
            },
            "type": "ApiConnection"
        }

如标题中所述，我遇到的问题是触发器仅在 30 分钟轮询重复时触发，如下所示，而不是在消息进入服务总线时触发（与我们也使用的常见数据服务触发器不同在创建/更新/删除时立即触发）。这是设计使然还是我设置错误？

逻辑应用运行 - 服务总线触发器

另一个问题是并发设置实际上只允许 25 个通过，并将其余部分保留在服务总线中直到下一次运行，因此我们不得不在处理之间等待很长时间。我认为并发设置的重点是让逻辑应用程序运行在队列中等待，然后当一个完成时另一个可以启动。正如您在我上面粘贴的图片中看到的那样，这并没有发生。3.45 运行从数据库中提取了 43 条记录。只有 25 个在 4.00 触发，还有 17 个留在服务总线上，直到下一次在 4.30 运行。如果我们发送大量数据，这有可能成为一个巨大的瓶颈。

服务总线设置也在下面，如果任何人都感兴趣的话：

Topic:
"properties": {
            "defaultMessageTimeToLive": "P5D",
            "maxSizeInMegabytes": 1024,
            "requiresDuplicateDetection": true,
            "duplicateDetectionHistoryTimeWindow": "PT1H",
            "enableBatchedOperations": true,
            "status": "Active",
            "supportOrdering": true,
            "autoDeleteOnIdle": "P10675199DT2H48M5.4775807S",
            "enablePartitioning": false,
            "enableExpress": false
        }
Subscription:
"properties": {
            "lockDuration": "PT5M",
            "requiresSession": false,
            "defaultMessageTimeToLive": "P5D",
            "deadLetteringOnMessageExpiration": true,
            "deadLetteringOnFilterEvaluationExceptions": true,
            "maxDeliveryCount": 1,
            "status": "Active",
            "enableBatchedOperations": true,
            "autoDeleteOnIdle": "P5D"
        }

提前致谢

4

2 回答 2

0

这是设计使然还是我设置错误？

Service Bus触发器是这样设计的，因为它是一个并且polling trigger将在interval您指定的位置运行，请参阅触发器概述：

每个工作流都包含一个触发器，它定义了实例化和启动工作流的调用。以下是一般触发器类别：

  • 轮询触发器，定期检查服务的端点
  • 推送触发器，它创建对端点的订阅并提供回调 URL，以便端点可以在指定事件发生或数据可用时通知触发器。然后触发器在触发之前等待端点的响应。

另一个问题是并发设置实际上只允许 25 个通过，并将其余部分保留在服务总线中直到下一次运行，因此我们不得不在处理之间等待很长时间。

你试过关掉Concurrency Control。根据描述，关闭Concurrency Control可以运行尽可能多的并行实例，但是一旦设置Concurrency Control开启，就无法关闭。您可能需要重新创建一个Azure logic app，或设置Concurrency Control为可能的最大值，最大值为 50。

1.

在此处输入图像描述

2.

在此处输入图像描述

于 2021-02-10T09:07:31.997 回答
0

正如弗兰克所说，逻辑应用程序适用于轮询机制，一种选择是您可以减少轮询间隔时间。但每次投票都算作一次操作，因此逻辑应用程序的成本会上升。所以请记住这一点。您可以增加并发性以从服务总线中获取更多数量的消息。

您要考虑的另一个选项是将 Azure Functions 与服务总线触发器一起使用。这将是一个直接的触发因素，但是是的涉及编码而不是配置。

于 2021-02-10T09:48:25.957 回答