Elsa工作流上下文分叉并行执行的并发一致性及乐观锁问询

问题背景 #

我在Elsa工作流的上下文（Workflow Context）中设置了player对象，对其内部并发管理机制存在疑问：一个FORK活动包含3个后续并行执行的活动，每个活动都会从上下文中获取player对象、修改后再放回上下文。想问Elsa是否具备乐观锁（Optimistic Locking）能力？要怎么保障这3个并行活动的修改一致且不互相覆盖？此前已尝试使用自定义工作流提供者进行测试。

核心结论 #

Elsa工作流的上下文默认不具备乐观锁机制，并行活动对上下文对象的修改会直接覆盖——因为上下文本质是一个共享的键值存储/对象，并行分支的修改独立执行后合并，没有内置的冲突检测与处理逻辑。

解决并行修改覆盖的可行方案 #

针对3个并行活动修改同一player对象的场景，可通过以下方式规避覆盖问题：

1. 采用「增量输出+统一合并」模式 #

不让每个并行分支直接修改上下文里的player对象，而是让分支输出修改指令/增量数据，最后用一个专门的「合并活动」汇总所有增量，再统一更新上下文的player对象。
示例流程：

• 分支1：计算玩家经验值增量，输出{ "expDelta": 100 }
• 分支2：计算玩家金币增量，输出{ "goldDelta": 50 }
• 分支3：标记玩家任务完成状态，输出{ "taskCompleted": true }
• 合并活动：读取三个分支的输出结果，一次性更新上下文的player对象，从根源避免并发覆盖。

2. 引入分布式锁控制上下文访问 #

如果必须让每个分支直接修改player对象，可通过分布式锁（如Redis锁）强制串行化修改操作：

• 在每个分支活动的开头，获取针对「当前工作流实例ID + player标识」的排他锁
• 锁获取成功后，读取上下文的player对象，修改后写回上下文
• 操作完成后立即释放锁
  这种方式会将并行执行转为串行，适合修改逻辑简单、对性能要求不高的场景。

3. 在自定义上下文存储中实现乐观锁 #

你之前尝试过自定义工作流提供者，可以在自定义实现中手动加入乐观锁逻辑：

• 给上下文存储实体添加版本号字段（如Version）
• 读取上下文时记录当前版本号，写回时校验版本号是否与读取时一致
• 若版本号不一致，说明有其他分支已修改上下文，触发重试或冲突告警逻辑

额外提示 #

Elsa的并行活动基于工作流实例异步调度，默认情况下各分支的上下文修改是独立的，最终合并时会以最后完成的分支修改为准，因此必须通过上述手段主动控制并发冲突。

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