Question

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

通常有两个逻辑应用程序，第一个每半小时（在 15 点和 45 点）从我们的数据库中提取数据并将其放置到选择的服务总线主题上，第二个使用“当 a在主题订阅中收到消息（自动完成）”触发器连接器 - 默认并发设置 (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 分钟轮询重复时触发，如下所示，而不是在消息进入服务总线时触发（与常见的数据服务触发器不同）我们还使用它立即在创建/更新/删除时触发）。这是设计使然还是我设置错误？

Logic App Runs - Service Bus Trigger

另一个问题是并发设置实际上只让 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"
        }

提前致谢

Answer 1

<块引用>

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

Service Bus触发器是这样设计的，因为它是一个polling trigger，会在你指定的interval上运行，请参考Triggers overview：

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

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

<块引用>

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

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

1.

2.

Answer 2

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

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

Azure 逻辑应用程序 - 服务总线触发器仅在轮询重复时触发

2 个答案: