首页 > 解决方案 > 将 Azure Functions 与事件中心链集成的最佳参数是什么

问题描述

我们需要设置 4 个 EventHub 和 3 个 Azure Functions。那么,拥有高吞吐量和可扩展参数的最佳方法是什么,我们可以设置一个可以处理 75k 消息/秒的系统呢?

标签: azureazure-functionsstreamingazure-eventhubthroughput

解决方案


这篇文章绝对值得一读,并且是我的一些工作的基础,我需要达到 50k p/sec。https://azure.microsoft.com/en-gb/blog/processing-100-000-events-per-second-on-azure-functions/

一个重要的考虑因素是您将拥有多少个分区,因为这将直接影响您的总吞吐量。当您横向扩展应用程序实例时,事件处理器主机 (EPH) 将尝试获取处理特定分区的所有权,并且每个分区可以处理 1MB/秒的入口和 2MB/秒的出口。(或者,每秒 1000 个事件)

https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-faq

您需要同时考虑消息大小和消息计数。如果可能,将尽可能多的数据点填充到事件中心消息中。在我的场景中,我在每个事件中心消息中处理 500 个数据点 - 从单个消息中提取大量数据而不是从大量消息中提取少量数据要高效得多。

对于您的吞吐量要求,这是您需要考虑的事情。即使有 32 个分区,这也不会给您 75k msg p/sec - 您可以要求 Microsoft 增加分区数,就像他们在我链接的原始文章中所做的那样,他们有 100 个分区。

至于配置设置:我正在运行

{
    "version":  "2.0",
    "extensions": {
        "eventHubs": {
            "batchCheckpointFrequency": 10,
            "eventProcessorOptions": {
                "maxBatchSize": 256,
                "prefetchCount": 512,
                "enableReceiverRuntimeMetric": true
            }            
        }
    }
}
  • 我收到一批消息,最多 256 条
  • 每条消息最多可包含 500 个数据点
  • 我们在 10 个批次后检查一个分区

这意味着有多达大约 130 万个数据点可以再次处理,以防导致函数必须从最后一个已知检查点开始处理。这也很重要 - 您的更新是幂等的,还是重新处理它们无关紧要?

您将需要将消息中的数据放入某种数据存储中,并且您将以高速率插入其中 - 您的目标数据存储能否应对这种高频率的插入?如果您的目标商店出现中断,您的处理管道会发生什么情况?我采用了与本文所述类似的方法,总结为“如果在处理一批消息时发生任何故障,请将整个批次移动到一个‘错误’集线器上,让另一个函数尝试处理它们”。你不能停止处理这个量,否则你会落后!

https://blog.pragmatists.com/retrying-consumer-architecture-in-the-apache-kafka-939ac4cb851a

这也是很重要的一点。您的处理需要多实时?如果您开始落后,您是否需要扩大规模以追赶上来?你怎么知道这是否正在发生?我创建了一个指标来跟踪任何分区的最新事件落后多远,这使我可以可视化并设置警报 - 我还根据这个数字扩展我的功能。

https://medium.com/@dylanm_asos/azure-functions-event-hub-processing-8a3f39d2cd0f

在您提到的卷中-不仅仅是一些配置可以让您实现它,还有许多考虑因素


推荐阅读