2

Mass Transit 有一个内存中的“发件箱”实现，我认为它可以处理我希望克服的大部分问题/挑战，但是我找不到很多详细描述我正在寻找的功能的文档。在观看了 Udi Dahan 解释如何在没有分布式事务的情况下处理可靠消息传递的视频 ( https://vimeo.com/111998645 ) 之后，出现了很多这些问题。

  1. 内存中的发件箱是否处理尝试向队列发送消息时可能发生的故障？例如：消费者生成 3 条消息，这些消息收集在发件箱中。消费者完成没有问题。发件箱中收集的消息开始被处理
    • 如果由于某种原因在处理收集的消息时出现网络问题（或其他问题）并且消息 2 无法发送，消息 2 和 3 会发生什么情况？是否有任何类型的重试策略？
    • 如果发件箱中正在处理的邮件成功添加到队列中但未成功标记为在发件箱中已发送，会发生什么情况？是否会再次尝试将消息发送到队列？
    • 假设如果出现某种故障，发件箱将重试向队列发送消息，那么消息 ID 是否保证在尝试之间保持一致？拥有一致的消息 ID 对于重复数据删除很重要，以确保我们不会多次处理相同的消息。
  2. 当一条消息被消费时，是否会发生任何重复数据删除？（这与 1.C 相关）
    • Mass Transit 如何跟踪每位消费者的已处理记录？存储引擎是否负责此责任？
  3. 是否有任何类型的“事务”暴露给消费者，允许您在不引发异常的情况下清除发件箱中收集的消息，或者抛出异常是回滚发件箱的唯一方法？
    • 消费者外部生成的消息怎么样，有没有办法回滚在发件箱中收集的消息（例如：WebAPI 控制器操作）？
  4. 是否建议使用 Mass Transit 的 DTC 功能而不是发件箱，反之亦然，或同时使用它们？
  5. 目前，Mass Transit 没有可以在进程崩溃后幸免于难的发件箱实现。有计划加入这样的功能吗？是否有跟踪此路线的路线图？
4

1 回答 1

1

  1. 内存中的发件箱推迟任何消息发送/发布/响应调用，直到消费者完成所有处理。这包括普通消费者和传奇。消费者做的最后一件事是发送/发布任何延迟消息，之后传入消息被确认（并从队列中删除）。话虽如此，您问题中的大多数其余项目都不相关，因为它不会将消息写入数据库，然后再处理它们。

  2. 不

  3. 不
  4. 不要使用 DTC，.NET Core 甚至不支持它
  5. 没有计划，没有路线图

正如您在开始时所说，内存中的发件箱处理 99.9% 的情况。精心设计的 saga 和支持服务可以将其推得更高，确保幂等性和最终成功的命令（或事件）处理。除了今天的东西之外，任何东西通常都是为了支持设计不佳的系统，并且只会产生过多的复杂性和额外的依赖关系。

于 2019-08-05T13:57:34.997 回答