将Azure函数与事件集线器链集成的最佳参数是什么？

Question

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

• Local.settings.json
• hosts.json
• 预取计数
• 最大批次侧

Answer 1

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

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

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

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

对于吞吐量需求，这是您需要考虑的问题。即使在32个分区，这也不会给你75k味精p/秒--你可以要求微软增加分区数量，就像他们在我链接的最初文章中所做的那样，他们有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

这也是很重要的一点。你的处理需要有多实时？如果你开始落后，你是否需要扩大规模来努力追赶？如果这事发生了你怎么知道？我创建了一个度量来跟踪任何分区的最新事件有多远，这允许我可视化并设置警报--我还根据这个数字扩展了我的函数。

asos/azure-functions-event-hub-processing-8a3f39d2cd0f

在您提到的卷-它不仅仅是一些配置将使您实现它，有许多注意事项

Answer 2

1. 如果您愿意编写更多的代码而不是使用Azure函数，那么在功能的吞吐量和灵活性方面，使用EventHub SDK编写自己的应用程序是很难克服的。
2. 一个伟大的博客Azure函数和事件中心:优化吞吐量。这是我对它的总结的总结(这也是最后)。

• 如果可能的话，可以批量发布。
• 保持分区计数高。
• 保持maxBatchSize尽可能高。(请记住，这只是一个函数运行时的建议，有太多的变量，即使您将maxBatchSize设置为一个很大的数字，也可能得不到足够大的批)
• 使用专用计划而不是消费。
• 为您的函数编写高效/快速的代码。

事件发布程序

• 使用批处理写信给EH (请注意大小限制！)顺便说一下，这个批次大小与maxBatchSize无关。
• 使用AMQP提高效率
• 如果报告应用程序时间，请使用UTC
• 如果使用分区关联，请避免通过选择错误的分区键来创建热分区，这将在处理端造成倾斜。如果您的场景不需要FIFO或顺序处理(只能在单个分区内实现)，则根本不要为循环写入指定分区id。更多的阅读

事件集线器

• 适当地选择分区的数量，因为它定义了并行使用者的数量。这里有更多的细节
• 对于高吞吐量方案，请考虑专用Azure事件中心。
• 当计算出您需要多少个吞吐量单位时，请同时考虑入口和出口侧。多个消费群体将竞争出口吞吐量。
• 如果您启用事件集线器捕获，您可以使用AVRO文件在Blob存储上触发冷路径/批处理，这也是一个受支持的触发器

事件集线器触发器设置：host.json和function.json

• 显式地将function.json中的“基数”设置为“多”，以支持消息的批处理
• maxBatchSize in host.json:默认设置64可能不足以让您重新进行管道、调整、度量和调整。请记住，编辑host.json将重新启动Azure函数
• prefetchCount in host.json:此设置的含义是“在将消息以批形式提供给函数之前要获取和缓存多少条消息。我通常将其显式设置为2*maxBatchSize。顺便说一句，将其设置为低于maxBatchSize的任何值都会减少批处理大小，从而对性能产生负面影响。
• batchCheckpointFrequency in host.json:查看与Azure函数关联的存储帐户，您将看到检查点是如何作为每个用户组每个分区的小json文件存储的。默认设置1告诉Azure函数在成功处理每个批处理后创建检查点。如果代码成功运行，批处理将被视为成功处理(您仍然负责捕获异常)。我通常从默认值1开始，并在看到与函数相关的存储帐户上的节流事件时稍微增加这个值(当多个Azure函数共享一个存储帐户时，情况会变得特别糟糕)。增加batchCheckpointFrequency的缺点是，在崩溃的情况下，您的函数必须重播自上一个检查点以来的更多消息。

Azure函数

• 确保您的代码是为处理可变大小的批处理事件编写的。
• 使用非阻塞异步代码
• 启用应用程序洞察，但要仔细评估所需的遥测量，并相应地调整host.json中的聚合和采样设置
• 通过删除AzureWebJobsDashboard应用程序设置禁用内置日志。默认情况下，Azure函数记录到Blob存储，在高工作负载下，您可能会因为节流而丢失遥测
• 从性能角度看，消费计划可能并不总是合适的，考虑使用Premium计划，或者在适当大小的VM/容器上部署事件处理器主机
• 在处理Azure事件中心时，没有“锁定”、“死信”等概念，请确保在单个消息级别处理异常。关于这个主题的精彩文章就在这里。