这个问题是关于并发访问 saga 数据的，当 saga 数据保存在 Azure 表存储中时。它还参考了 Particular 文档中的信息：http: //docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency
我们注意到，在单个 saga 并发执行处理程序中，对 saga 数据的修改似乎是在“最后一个将更改发布到 azure table storage 获胜”的场景中进行的。将 NSB 与 Azure 表存储结合用作 Saga 数据持久层时，这是预期的行为吗？
例子：
- Saga Data 中的整数属性，假设它当前 = 5
- 在这个传奇中，5 个命令由同一处理程序的 5 个实例处理
- 每个命令处理程序都会递减 saga 数据中的整数属性
- 在处理这 5 条消息后，saga 数据中整数属性的最终值实际上可能是 4 - 如果每条消息都由 saga 的新实例处理，可能在不同的服务器上，每个服务器都有一个 saga 数据的副本，指示整数属性为 5 ，将其减至 4，然后备份。我刚刚描述的是一个非常并发的例子，但是如果同时处理 5 条消息中的任何一条，整数很可能大于 0，saga 数据整数属性达到 0 的唯一时间是 5 条命令恰好执行串行。
另外，由于 Azure 表存储支持乐观并发，是否可以像使用 Raven 作为持久性技术时为 RavenDB 启用此功能一样为表存储启用此功能？
如果这是不可能的，那么推荐的处理方法是什么？目前，我们正在订阅这样一种范式，即 saga 中可能同时处理多个消息的任何处理程序都不允许修改 saga 数据，这意味着我们对 saga 消息的协调是通过 saga 外部的方式完成的，而不是使用 Saga 数据正如我们最初的意图。