我是Rebus的新手，正在努力了解我们目前在Azure Logic应用程序中使用的一些模式。当前的目标实现将使用Azure Service Bus和Saga存储，最好是在Cosmos DB中(仍在调查该示例实现)。甚至可能使用Rebus Mongo DB和Cosmos DB使用Mongo DB API(但不确定这是否可能)。
我们的一个主要用例是事件/超时模式，在阅读了一些示例/论坛/堆栈溢出之后，这种情况并不少见。棘手的部分是，我们的传奇行为更像是一个有限状态机，而不是一个有向无循环图。这主要是因为日期在外部发生了更改，因此事件的超时也发生了更改。
Defer()方法不返回超时标识符，我们认为这是一个实现限制(Azure Service Bus返回一个long)。由于我们必须忽略为一个事件安排的超时，而该事件现在已经在时间上发生了变化，我们看到了一种使这些超时"发生"的方法；忽略"；(因为不能取消)如下：
-
在我们自己的
SagaData派生基类中使用Dictionary<string, Guid>，其中键是超时消息类型的某种派生，Guid是创建超时消息时给它的标识符。我不认为这需要一本并发词典，但这就是我在这里的原因。。。 -
在接收到事件消息时，从上述字典中删除相应的超时消息类型密钥；
-
收到超时消息时：
- 如果超时消息类型键不存在或Guid与字典键/值不匹配，则忽略；其他
- 过程。在这一点上，我们也可以删除字典键
-
当事件重新安排时，只需添加超时消息类型/Gid字典条目，或使用新的超时消息Guid更新Guid。
这是正确的做法，还是有更"正确"的方式来处理无效的超时(延迟)消息？
你在的正确轨道上
我不认为这需要一个并发字典，但这就是我在这里的原因。。。
Rebus允许您的传奇处理程序处理自己的传奇数据副本(使用乐观并发)，因此您可以自由地对传奇数据建模，就好像一次只有一个人访问它一样。