Mass Transit 有一个内存中的“发件箱”实现,我认为它可以处理我希望克服的大部分问题/挑战,但是我找不到很多详细描述我正在寻找的功能的文档。在观看了 Udi Dahan 解释如何在没有分布式事务的情况下处理可靠消息传递的视频 ( https://vimeo.com/111998645 ) 之后,出现了很多这些问题。
- 内存中的发件箱是否处理尝试向队列发送消息时可能发生的故障?例如:消费者生成 3 条消息,这些消息收集在发件箱中。消费者完成没有问题。发件箱中收集的消息开始被处理
- 如果由于某种原因在处理收集的消息时出现网络问题(或其他问题)并且消息 2 无法发送,消息 2 和 3 会发生什么情况?是否有任何类型的重试策略?
- 如果发件箱中正在处理的邮件成功添加到队列中但未成功标记为在发件箱中已发送,会发生什么情况?是否会再次尝试将消息发送到队列?
- 假设如果出现某种故障,发件箱将重试向队列发送消息,那么消息 ID 是否保证在尝试之间保持一致?拥有一致的消息 ID 对于重复数据删除很重要,以确保我们不会多次处理相同的消息。
- 当一条消息被消费时,是否会发生任何重复数据删除?(这与 1.C 相关)
- Mass Transit 如何跟踪每位消费者的已处理记录?存储引擎是否负责此责任?
- 是否有任何类型的“事务”暴露给消费者,允许您在不引发异常的情况下清除发件箱中收集的消息,或者抛出异常是回滚发件箱的唯一方法?
- 消费者外部生成的消息怎么样,有没有办法回滚在发件箱中收集的消息(例如:WebAPI 控制器操作)?
- 是否建议使用 Mass Transit 的 DTC 功能而不是发件箱,反之亦然,或同时使用它们?
- 目前,Mass Transit 没有可以在进程崩溃后幸免于难的发件箱实现。有计划加入这样的功能吗?是否有跟踪此路线的路线图?