将Azure功能与事件中心链集成的最佳参数是什么

我们需要设置4个EventHub和3个Azure函数。那么，什么是获得高吞吐量和可伸缩参数的最佳方法，我们可以将其设置为具有每秒可处理75k消息的系统

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

---

这篇文章绝对值得一读，我的一些工作是基于这篇文章的，我需要达到50k p/sec

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

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

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

至于配置设置：我正在使用

{
    "version":  "2.0",
    "extensions": {
        "eventHubs": {
            "batchCheckpointFrequency": 10,
            "eventProcessorOptions": {
                "maxBatchSize": 256,
                "prefetchCount": 512,
                "enableReceiverRuntimeMetric": true
            }            
        }
    }
}

• 我收到一批消息，最多256条
• 每条消息最多可包含500个数据点
• 我们在10批之后检查一个分区

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

您需要将消息中的数据放入某种类型的数据存储中，并且您将以高速率插入其中-您的目标数据存储能够处理如此高频率的插入吗？如果目标存储中断，处理管道会发生什么情况？我采用了本文中描述的类似方法，总结为“如果在处理一批消息时出现任何故障，请将整个批移到“错误”中心，让另一个函数尝试并处理它们”。您不能停止处理此卷，否则您将落后

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

在您提到的卷上，不仅仅是一些配置可以让您实现它，还有一些考虑因素

如果您愿意编写更多的代码，而不是使用Azure函数，那么在吞吐量和功能灵活性方面就很难击败它

一个很棒的博客。这是我对它的总结（也在最后）

• 如果可能，分批发布
• 保持分区计数高
• 尽可能保持

  maxBatchSize

  高。（请记住，这只是对函数运行时的建议，变量太多，即使将

  maxBatchSize

  设置为一个较大的数字，也可能无法获得足够大的批）
• 使用专用计划，而不是消耗
• 为您的函数编写高效/快速的代码

---

事件发布者

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

活动中心

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

事件中心触发器设置：host.json和function.json

• 在function.json中将“cardinality”显式设置为“many”，以启用消息批处理
• host.json中的maxBatchSize:默认设置64可能不足以让您再次进行管道、调整、测量和调整。请记住，编辑host.json将重新启动Azure功能
• host.json中的prefetchCount：此设置的含义是“在批量将maxBatchSize消息提供给函数之前，要获取和缓存多少消息。我通常将其显式设置为2*maxBatchSize。顺便说一句，将其设置为maxBatchSize以下的任何值都会降低批量大小，从而对性能产生负面影响
• host.json中的batchCheckpointFrequency：查看与Azure函数关联的存储帐户，您将看到检查点是如何存储为每个分区每个cons的小json文件的