.NET 6消费型Azure函数使用Durable Entity存储跨运行状态可行性咨询

Durable 实体使用问题解答 #

存储上限说明 #

Durable 持久实体没有官方公布的固定存储上限，其限制来自底层依赖的 Azure 存储服务：

• 序列化后状态小于 1MiB 时，数据直接存入 Azure 表存储单条记录，读写性能最优，也是官方推荐的单个实体状态体量范围
• 超过 1MiB 的状态会被 Durable 运行时自动拆分存入 Blob 存储，读写延迟会明显升高，且更容易出现一致性问题

测试返回旧数据的常见原因 #

你遇到的状态更新不生效、返回旧数据的问题，可优先排查以下几点：

1. 代码笔误：你贴出的代码中，SetComplicatedObject 方法赋值的属性名为 ComplicatedObject，但类中定义的存储属性是 ComplicatedData，如果实际运行代码和示例一致，会直接导致状态更新不生效
2. 调用方式错误：从普通非 Durable 函数调用实体写操作时，如果使用了 SignalEntityAsync（发即忘模式），调用后立即读状态的话，写操作可能还未入队执行，读到的就是旧数据，需要确认写完成的场景必须使用 CallEntityAsync 等待操作完成
3. 本地存储模拟器缺陷：本地测试用的 Azurite 或 Azure Storage Emulator 对大体积状态的事务一致性处理存在已知 Bug，相同代码部署到 Azure 云环境后复现概率会大幅降低

场景可行性判断 #

你常规使用场景是存储数百条由字符串、整型、日期组成的对象数组，序列化后的大小基本不会超过 1MiB，使用持久实体是完全可行可靠的，只需注意以下优化点：

• 单个实体存储的状态不要超过 10MiB，超过建议拆分多个实体或更换存储方案
• 可开启 Durable Functions 的状态压缩配置，进一步降低存储体积、提升读写速度
• 生产环境避免使用 SignalEntityAsync 执行需要确认结果的写操作

替代存储方案参考 #

如果后续状态体量持续增大，可选择更匹配的跨运行状态存储方案：

• Azure 表存储：直接操作表存储，单条记录 1MiB 上限，读写延迟低，开发成本极低
• Azure Redis 缓存：适合高频读写场景，支持过期策略，性能最优
• Azure Cosmos DB：单条记录默认支持 2MB 存储（可提额到 16MB），一致性级别可配置，适合大规模状态存储场景

内容的提问来源于stack exchange，提问作者Tarostar