主/子Orchestrator用Durable Entity共享数据是否违反确定性规则

只要严格遵守Durable Functions的Entity调用规范，单个Durable Entity完全可以安全用于主Orchestrator与所有子Orchestrator之间的公共数据共享，不会违反确定性规则，你最初的判断方向是正确的，但需要注意几个容易被忽略的约束，踩中就可能触发非确定性问题。

合规性核心依据 #

• Durable Entity的所有交互都被纳入Durable Task Framework的持久化调度体系：Orchestrator对Entity发起的调用请求、返回结果、状态变更都会完整写入实例历史。Orchestrator重放时不会实际发起新的Entity调用，只会从历史记录中读取固定的返回结果，天然满足确定性要求。
• Durable Entity自带单线程串行执行的并发控制机制，所有来自主Orchestrator、不同子Orchestrator的操作请求会按接收顺序排队执行，不会出现多调用方并发写入导致的状态竞态、读写冲突问题。

必须严格遵守的调用约束 #

• 所有和Durable Entity的交互必须通过Orchestrator上下文提供的标准接口完成，包括CallEntityAsync、SignalEntity，绝对不要通过静态变量、自定义单例等方式绕开框架直接访问Entity的内存状态，这类绕开持久化层的读写是典型的非确定性来源。
• 如果需要读取Entity状态作为后续业务分支的判断依据，必须使用带返回值的CallEntityAsync方法等待结果返回后再执行后续逻辑，不要使用发后即忘的SignalEntity触发状态更新后，立刻在同一段Orchestrator逻辑中默认状态已经完成变更——Signal操作是异步投递的，首次执行和重放时的执行时序一旦出现偏差，就会生成完全不同的执行路径。
• Entity本身的操作逻辑中禁止嵌入非确定性代码：包括调用外部接口、获取系统当前时间、生成随机数、获取本地环境变量等，Entity操作的执行结果会被持久化，操作本身如果存在非确定性，重放时会直接出现状态不一致。
• 不要给所有子Orchestrator开放Entity的全量写入权限，最好提前预定义固定的状态操作集合，所有状态变更都走预定义的操作入口，避免不同子Orchestrator随意覆盖公共状态导致的逻辑冲突。

容易忽略的实践坑点 #

• 注意Entity的锁粒度问题：如果调用Entity的操作需要持有临界区锁，不要在锁持有期间调用长耗时的子Orchestrator逻辑，否则会导致锁被长时间占用，其他调用方排队超时，整体调度性能下降。
• 控制共享Entity的状态大小：Entity的状态会随操作记录一起持久化到后端存储，不要将体积过大的对象存入共享Entity，避免触发单条存储条目大小限制，导致持久化失败、操作延迟升高。

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