Mule ESB：如何在MULE ESB中实现典型的重试机制


Mule ESB: How to achieve typical ReTry Mechanism in MULE ESB

我需要实现一个重试逻辑。入站端点将消息推送到 Rest(出站)。如果 REST 不可用，我需要重试 1 次并将其放入队列中。但是第二个即将到来的消息不应该做任何重试，它必须直接将消息放入队列，直到 REST 服务可用。

一旦服务可用，我需要通过批处理作业将所有消息从 QUEUE 推送到 REST 服务(按顺序)。

问题：

  • 我如何知道我的第二条消息无法使用该服务？如果我使用直到成功，对于每条消息，它都会重试并放入队列。 Plm 是第二条消息不应该重试。

  • 对于批处理，我想过使用轮询，但是如何告诉轮询，何时服务可用以开始批处理。 (bcz，Poll 更多的是配置运行批处理的时间)？

  • 其他让我感到困惑的是 - 这里的顺序必须保留。一旦服务可用。队列消息(即批处理)必须首先移动到 REST 服务，然后才能实时移动。我怀疑它是否适用。

    对快速响应实现逻辑很有帮助。

    • 使用骡子：3.5.1

    我可以尝试以下方法：使用流控制

  • 处理消息；如果出现异常或错误的响应代码，请设置一个变量/属性，如 serviceAvailable=false。
  • 后续的消息处理会先检查属性 serviceAvailable 来处理消息。如果属性为假，则将消息排队到状态=新/未处理的数据库表
  • 创建一个流/调度程序来按顺序处理来自 DB 的消息，但它不会检查属性 serviceAvailable 并调用其余服务。
    如果服务抛出异常，它将不会再次将消息存储在数据库中，但如果进程成功更改属性 serviceAvailable=true 并将消息出队或更改状态。如果 db 表中有更多消息，例如 moreDBMsg=true，则添加另一个属性并将其设置为 true。
    在 moreDBMsg=false 之前，不应处理/消费新消息
    再一次 DBMsg=false 和 serviceAvailable=true 开始处理来自队列的消息。
    • 相关讨论

    对于超时，我仍然会查看响应代码并捕获超时以确定调用是否成功或需要重试。实际上，无论如何您通常都会进行多线程处理，因此无论如何您都有多个并行调用。或者只是一个电话在另一个电话结束之前开始。
    这很正常。

    但是您可以简单地在超时的队列中重试呼叫。在 x 次超时后，您"跳过"或推迟重试。

    但所有这些都是使用实际的 Mule 流组件完成的，例如：

    • MEL http://www.mulesoft.org/documentation/display/current/Mule 表达式语言参考
    • 或流控制：http://www.mulesoft.org/documentation/display/current/Choice Flow Control Reference
    • 或者例如，您引用一个 Spring Bean 并在本机 Java 代码中执行此操作。

    队列的一种可能性是将其保存在数据库中。 Mule 具有具有"轮询"功能的数据库连接器，请参阅：http://www.mulesoft.org/documentation/display/current/JDBC 传输参考#JDBCTransportReference-PollingTransport

    相关讨论