c# - Azure 持久实体，用于存储运行之间的函数应用程序状态 (.net 6)

Question

我想每分钟运行一个简单的.net 6 c#消费azure函数应用程序(不持久)，但我需要记住上次运行的状态。

状态由 json 可序列化对象的数组和一些访问 token 字符串组成。

所以我创建了一个像这样的持久功能实体:

[JsonObject(MemberSerialization.OptIn)]
public class DurableStorageEntity
{
    [JsonProperty("simpledata")]
    public string SimpleData { get; set; }

    [JsonProperty("complicateddata")]
    public List<ComplicatedObject> ComplicatedData { get; set; }

    public void SetSimpleData(string data) => this.SimpleData = data;


    public void SetComplicatedObject(List<ComplicatedObject> data) => this.ComplicatedObject = data;

    [FunctionName(nameof(DurableStorageEntity))]
    public static Task Run([EntityTrigger] IDurableEntityContext ctx)
        => ctx.DispatchAsync<DurableStorageEntity>();
}

这效果很好，但我不确定这有多高效以及我可以通过这种方式存储多少状态数据。经过测试后，我也不确定从常规(即非持久)函数应用程序调用时这是否可靠。

我找不到这方面的任何明确信息。在 MS document on Entity Functions它只是指出:

Entity functions define operations for reading and updating small pieces of state, known as durable entities.

还有

Entities provide a means for scaling out applications by distributing the work across many entities, each with a modestly sized state.

所以这让我不确定我可以存储多少数据。我通常会存储几个包含数百个项目的数组，每个对象由字符串、整数和日期组成。如果有更好的方法来存储运行之间的状态，那么欢迎使用替代方案，但我确实喜欢使用这些实体函数，所以我希望它是一个可行且可靠的选择。

12 月 2 日更新:

我一直在测试使用 100 项对象数组(字符串、整数、日期时间)存储对象列表。

我在我的机器上本地运行它。我可能做错了什么，但有时它会返回我之前存储的旧数据，而不是持久实体存储中存储的最新数据。我不知道为什么会发生这种情况。我可以通过存储大量数据来实现它，但它在其他时候也会随机发生。

生成了 100 个对象大小:6 365 853 字节读取时间:250ms写入时间:215ms

生成了 1000 个对象大小:63 658 851 字节读取时间:2s 659ms写入时间:1s 811ms

生成了 10000 个对象写入似乎成功，但读取时得到了之前的 1000 个对象

生成了 10 个对象按预期读回 10 个对象

生成了 2000 个对象错误:仍然获取 10 个对象

生成了 1000 个对象错误:仍然获取 10 个对象

生成了 100 个对象错误:仍然获取 10 个对象

生成了 1 个对象终于如愿拿回了 1 个对象

生成了 10 个对象错误:三次运行仍然获得 1 个对象，但在第四次运行函数应用程序时突然获得 10 个对象，因为它应该。

这是在我的本地计算机上，win10，i7，32Gb RAM，并且在 VS2022 中没有调试器。

Answer 1

是的，这可能是预期的结果。这并不是说实体不可靠。它们工作得很好，并且对于存储功能数据来说是可靠的，但它们可以有延迟更新，使系统像任何分布式系统一样工作。持久实体是一个基于队列的系统，基于 azure 存储队列和表工作。当为 SetComplicatedObject 创建 SignalEntityAsync 时，它将在队列中创建一条消息。然后实体将在某个时刻执行 SetComplicatedObject。可能会立即发生，也可能在执行前延迟一段时间发生。在执行之前，将从 azure 表中读取实体。然后它将执行并将其保存回表中(如果实体太大，将使用 blob)。当实体对象变大时，读取和保存将花费更长的时间，因此实体可能需要更长的时间才能完成信号和更新。

在 Azure 函数中，ReadEntityState 将从表中读取数据(提交的数据)。因此读取的数据可能会也可能不会完全更新。

根据你的解释，我认为触发器看起来像这样。将复杂对象更改为 int 列表并添加第二次读取以说明更新更改。

public static int Ptr = 0;
public static int[] Sizes = new int[] { 0, 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000};
[FunctionName("Function1")]
public async Task Run([TimerTrigger("0 */1 * * * *")]TimerInfo myTimer, ILogger log, [DurableClient] IDurableEntityClient client)
{
    var entityId = new EntityId(nameof(DurableStorageEntity), "test");
    await client.SignalEntityAsync(entityId, "SetComplicatedObject", new List<int>(new int[Sizes[Ptr]]));
    await Task.Delay(500);
    var item1 = await client.ReadEntityStateAsync<DurableStorageEntity>(entityId);
    await Task.Delay(1000);
    var item2 = await client.ReadEntityStateAsync<DurableStorageEntity>(entityId);
    log.LogInformation($"End - Expected size: {Sizes[Ptr]} - Item1 size: {item1.EntityState.ComplicatedData.Count} - Item2 size: {item2.EntityState.ComplicatedData.Count}");
    Ptr++;
}

这产生了输出(运行不同时间时可能会有所不同)

End - Expected size: 0 - Item1 size: 0 - Item2 size: 0
End - Expected size: 1 - Item1 size: 1 - Item2 size: 1
End - Expected size: 10 - Item1 size: 10 - Item2 size: 10
End - Expected size: 100 - Item1 size: 100 - Item2 size: 100
End - Expected size: 1000 - Item1 size: 1000 - Item2 size: 1000
End - Expected size: 10000 - Item1 size: 10000 - Item2 size: 10000
End - Expected size: 100000 - Item1 size: 100000 - Item2 size: 100000
End - Expected size: 1000000 - Item1 size: 1000000 - Item2 size: 1000000
End - Expected size: 10000000 - Item1 size: 1000000 - Item2 size: 10000000

请注意上次运行的“错误”，其中 Item1 不正确，但又过了一秒，Item2 获得了正确的项目，因为表中的实体在读取之间进行了更新。

持久实体无法保证所有更新均已执行。那么您可能必须切换到其他一些数据存储解决方案。 Sql、NoSql 等。您还可以使用 Azure 表存储，但没有持久实体，只需立即在表中读取和更新。