如何解决大众运输:如何重新发布或发送否定确认?
我有多个微服务。他们目前通过消息代理进行通信,我正在使用 Masstransit rabbitmq。一切正常。
现在,我有一个案例,一个服务 A 发布一条消息,另一个服务 B 使用它。服务 B 会发送大量电子邮件,这需要一些时间。如果失败,它会调用一个新事件,我想在其中发送否定确认并希望服务 A 在一些延迟后重新发布。我知道我可以通过服务 B 消费方法中的异常,但这在这里是不可能的。发送电子邮件以独立的方式运行。如何将消息从服务 A 重新发布到 B?
解决方法
您的问题的答案与 MassTransit 或任何其他图书馆无关,您可以使用它来支持流程。您需要根据自己的需要设计消息流。
不是很清楚,为什么发送电子邮件需要一些时间,为什么会失败,因此以下纯基于假设。
如果服务 B 通过使用单个消息发送一批电子邮件,则它不是事务性的。如果它发送 100 封电子邮件并在 101 上失败,会发生什么?如果您有消息重试策略,它会再次发送前 100 封电子邮件。
我肯定会尝试限制单个消息范围来处理单个事务。将每个电子邮件发送操作拆分为它自己的消息并处理那些(可能是数千个)消息,这完全没问题。至少,在重试的情况下,它只会重试一个操作。确认每个单独的操作,而不是整个批次。服务 A 可以命令服务 B 发送大量电子邮件。服务 B 负责将需要发送的电子邮件数量拆分为多个单独的消息。服务 B 可以完美地向自己发送消息。
您如何处理错误是您自己的决定。对于我不得不处理发送电子邮件的所有情况,它是这样的:
- 每封电子邮件都是一条单独的消息
- 如果失败,我会检查原因是什么。通常,您不会立即从邮件提供商处收到失败消息,除非电子邮件地址明显不正确,或者提供商本身已关闭。
- 首先防止将消息发送到错误的电子邮件,您不需要因为这些明显的错误而使系统过载。
- 如果电子邮件提供商关闭,请相应地启用消息重试策略。如果您太用力并受到速率限制,请确保有一个断路器来管理来自提供商的背压。您还可以对自己的消费者进行速率限制。所有这些都是 MassTransit 中的内置中间件。
- 仅重试暂时性错误。如果错误是永久性的,则无需重试。
- 如果所有重试突然失败,您仍然可以进行重新交付。它内置于 MassTransit 中。不过,问自己一个问题,为什么它会发生?
- 从服务 A 向服务 B 发送 NACK 消息是微不足道的。如果发生错误,而不是为服务 A 抛出、发布或发送另一条消息。我认为这没有任何问题。
- 您始终可以通过查看消费者上下文元数据来检查您的重试或重新交付计数是否正在耗尽。如果所有重试都失败,您可以决定仅向服务 A 发送 NACK 消息。
- 抛出本身并没有错,因为您可以在那里获得重试和重新交付中间件来帮助您处理暂时性故障。如果这些策略用尽了它们的重试次数并且消息将进入中毒队列,则服务 A 始终可以侦听故障事件。中毒队列很有价值,因为它允许您分析故障的性质。
同样,这不是技术问题。您需要决定如何处理此工作流程。 MassTransit 将帮助您以您想要的方式实施它,但您首先需要决定您想要什么。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。