Azure 持久实体或静态变量？

Question

问题：使用静态变量（作为业务流程之间的共享存储）是线程安全的还是更好地将数据保存/检索到持久实体？

在同一个命名空间中有几个 azure 函数：hub-trigger、durable-entity、2 个编排（主进程和监视整个进程的一个）和活动。 他们都需要一些共享变量。就我而言，我需要知道主要编排实例的数量（开始新的或保留）。它在另一个编排（监视器）中完成

我已经尝试了这两个选项并询问，因为我看到了不同的结果。

静态变量：在我的例子中，有一个通用列表，其中 SomeMyType 保存任务的 ID、状态、尝试次数、处理的记录和其他信息。 当我需要开始新的编排和 List.Add() 时，当我需要检索和修改它时，我使用简单的 List.First(id_of_the_task)。 First() - 我确定需要的任务在那里。 使用静态变量，我有时会看到任务因某种原因而重复——我使用 List.First(id_of_the_task) 检索任务——更改结果变量的某些内容就是这样。代码不多。

持久实体：主要区别在于我在持久实体上添加 List 并且每次需要检索它时我都会调用 .CallEntityAsync("getTask") 和 .CallEntityAsync("saveTask ") 这可能会减慢应用程序的完成速度。 使用这种方法需要更多的代码和调用，但它看起来更稳定，我没有看到任何重复。

请指教

Answer 1

无法回答为什么您会在没有代码的情况下使用静态变量方法看到重复项，这可能是因为 list 不是线程安全的，它可能需要 ConcurrentBag 但不确定。静态变量的一个问题是函数应用程序是否始终处于打开状态，或者它是否可以有多个实例。因为当函数卸载（或崩溃）时，状态会丢失。静态变量也不跨实例共享，因此在高负载期间它不会工作（如果可以有很多实例）。

耐用的实体在这里看起来更好。是的，它们可以在许多并发函数实例之间共享，并且每个实体一次只能执行一个操作，因此它们肯定是更好的选择。性能成本略高，但它们不应该比编排器慢，因为它们执行许多常见操作、写入表存储、检查事件等。

不能说它是否适合您，但不是List.First(id_of_the_task)，您应该能够通过可以保存自定义数据的客户端访问编排器属性。取决于使用情况的另一个想法是，您可以直接使用 CloudTable 类查询表存储以获取有关正在运行的编排器的信息。

虽然不完全相关，但您可以查看一些用于持久功能的并行设置Azure (Durable) Functions - Managing parallelism

如果我应该澄清任何事情或者我误解了您的问题，请提出任何问题。