处理失效的延迟（超时）消息？
Handling defunct deferred (timeout) messages?
我是 Rebus 的新手，正在尝试跟上我们目前在 Azure 逻辑应用程序中使用的一些模式的速度。当前的目标实现将使用带有 Saga 存储的 Azure 服务总线，最好是在 Cosmos DB 中（仍在研究该示例实现）。甚至可以使用 Mongo DB API 将 Rebus Mongo DB 与 Cosmos DB 一起使用（尽管不确定这是否可能）。
我们的一个主要用例是 event/timeout 模式，在阅读 samples/forums/Stack Overflow 之后，这种情况并不少见。棘手的部分是我们的 Sagas 更像是一个有限状态机而不是一个有向无环图。这主要是因为日期在外部发生了变化，因此事件超时发生了变化。
Defer() 方法没有 return 超时标识符，我们认为这是一个实现限制（Azure 服务总线 return 很长）。由于我们必须忽略为现在已经及时转移的事件安排的超时，我们看到了一种“忽略”这些超时的方法（因为它们不能被取消）如下：
在我们自己的 SagaData 派生基础 class 中使用 Dictionary<string, Guid>，其中键是超时消息类型的某种派生，Guid 是创建时赋予超时消息的标识符。我不认为这需要是一个并发字典，但这就是我在这里的原因...
收到事件消息后，从上述字典中删除相应的超时消息类型键；
收到超时消息时：
- 如果超时消息类型键不存在或 Guid 与字典不匹配则忽略 key/value；其他
- 进程。我们也可以在此时删除字典键。
发生事件重新安排时，只需添加超时消息 type/Guid 字典条目，或使用新的超时消息 Guid 更新 Guid。
这是在正确的轨道上，还是有更多 'correct' 处理失效超时（延迟）消息的方法？
你走在正确的轨道上
I don't believe this needs to be a concurrent dictionary but that is why I am here...
Rebus 让您的 saga 处理程序处理它自己的 saga 数据副本（使用乐观并发），因此您可以自由地对 saga 数据建模，就好像它一次只能被一个人访问一样。
我是 Rebus 的新手，正在尝试跟上我们目前在 Azure 逻辑应用程序中使用的一些模式的速度。当前的目标实现将使用带有 Saga 存储的 Azure 服务总线，最好是在 Cosmos DB 中（仍在研究该示例实现）。甚至可以使用 Mongo DB API 将 Rebus Mongo DB 与 Cosmos DB 一起使用（尽管不确定这是否可能）。
我们的一个主要用例是 event/timeout 模式，在阅读 samples/forums/Stack Overflow 之后，这种情况并不少见。棘手的部分是我们的 Sagas 更像是一个有限状态机而不是一个有向无环图。这主要是因为日期在外部发生了变化，因此事件超时发生了变化。
Defer() 方法没有 return 超时标识符，我们认为这是一个实现限制（Azure 服务总线 return 很长）。由于我们必须忽略为现在已经及时转移的事件安排的超时，我们看到了一种“忽略”这些超时的方法（因为它们不能被取消）如下：
在我们自己的
SagaData派生基础 class 中使用Dictionary<string, Guid>，其中键是超时消息类型的某种派生，Guid 是创建时赋予超时消息的标识符。我不认为这需要是一个并发字典，但这就是我在这里的原因...收到事件消息后，从上述字典中删除相应的超时消息类型键；
收到超时消息时：
- 如果超时消息类型键不存在或 Guid 与字典不匹配则忽略 key/value；其他
- 进程。我们也可以在此时删除字典键。
发生事件重新安排时，只需添加超时消息 type/Guid 字典条目，或使用新的超时消息 Guid 更新 Guid。
这是在正确的轨道上，还是有更多 'correct' 处理失效超时（延迟）消息的方法？
你走在正确的轨道上
I don't believe this needs to be a concurrent dictionary but that is why I am here...
Rebus 让您的 saga 处理程序处理它自己的 saga 数据副本（使用乐观并发），因此您可以自由地对 saga 数据建模，就好像它一次只能被一个人访问一样。