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) 检索任务 - 更改结果变量上的某些内容，就是这样。代码不多。

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

请多多指教

Answer 1

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

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

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

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

如果我需要澄清任何问题或者我误解了您的问题，请提出任何问题。