Spring Integration 消息重投最佳实践

Question

我目前正在使用 Spring Integration 开发一个应用程序。该应用程序需要有保证的交付，并且可以选择在外部系统不可用的特定时间内运行而不丢失消息。通道将由具有过期时间的 JMS 支持。我想了解哪个是使用 Spring Integration 重新交付的最佳实践。我们有以下选择：

1. 应用程序的集成流具有许多需要与外部系统进行 RPC 调用的出站消息网关。可以使用有状态的重试建议。在达到特定运行时异常的最大尝试次数后，消息将被发送到恢复通道。恢复通道将使用延迟器，然后将消息发送回原始通道。在消息到达恢复通道 X 次之后，它将被发送到错误通道，在那里它会被简单地记录下来，而无需进一步处理。在这种情况下，延迟器组件应该使用 jdbc 消息存储选项。

2. 另一个选项是使用标准 JMS 选项进行重新传递。在这种情况下，重新交付策略不会在 Spring Integration 上实现，而是在 JMS 提供者端实现。

使用 Spring Integration 重新传递消息的最佳实践是什么？

Answer 1

我会这样说：不要重新发明轮子！

如果已经有一些类似的解决方案，只需使用它的特定配置即可。

好吧，如果 JMS 有这个解决方案，那就继续吧。 当然，在消息过期或重新传递耗尽的情况下，需要处理 DLQ。但概念就在这里。