带有消息队列的生产者、消费者和处理程序答案

【问题标题】：Producer, consumer, and handler with messaging queue带有消息队列的生产者、消费者和处理程序
【发布时间】：2018-07-13 19:57:42
【问题描述】：

我参与了一个由以下应用组成的项目：

问题是：消费者从队列中取出消息，并将它们发送给处理程序。然后消费者被阻塞（通过使用异步的后台线程）等待处理程序的进程。即 Consumer 对 Handler 应用进行 RPC 调用。

如果 Handler 成功地将消息发送到外部应用程序，或者如果失败，则成功地将它们排入死队列，Consumer 提交出队。（从队列中删除消息）

如果上述两个（外部应用程序或死队列）中的任何一个都失败，则消费者回滚出队（将消息放回队列）

我的问题是

使用Handlers app的优缺点是什么，比较Consumer执行Handler的逻辑和Consumer当前的逻辑？
是不是可以把Handler应用去掉，把Handler的逻辑集成到Consumer应用？因此消费者直接与外部应用程序对话，并处理死队列。需要维护的应用程序少了一个。

【问题讨论】：

我没有看到任何将处理程序和消费者应用程序分开的优点。给定一个事实，通过在 MQ 消息传递之上构建 RPC 调用，您唯一拥有的就是带有额外 RPC 问题的消息传递。使用 MQ 或 RPC。

【解决方案1】：

让我们非常清楚：在抽象意义上，您有两个实体 - 生产者和消费者。生产者发送原始消息，消费者处理它。无需通过添加有关“处理程序”的详细信息来混淆水，因为它是消费过程的逻辑部分。

看来你的真正问题（也是我的）是“consumer（你的定义）增加了什么价值？”请记住，没有人直接相互“交谈”——他们通过消息队列进行通信。在这方面，如果让最终处理部分直接将消息出队而不是使用一些中间管道更容易，那么就这样做。

【讨论】：

这句话是什么意思？ “在这方面，如果让最终处理部分直接将消息出队而不是使用一些中间管道更容易，那么就这样做。”我们目前有生产者、消费者、队列和处理程序。您建议删除哪些部分？
“处理程序”在做什么？我指的是管道。这似乎是相当多余的。
Handler 基本上只是将消息从消费者传递到外部应用程序。
是的，这是多余的，因为这表面上是消息代理的工作。