-2

我想检查设计方法的可行性，以使用 JMS 或 ActiveMQ 或 RabbitMQ 等面向消息的中间件 (MOM) 技术来处理单个 Web 应用程序中的异步处理，即 MOM 服务器的发布者和订阅者将包含在相同的网络应用程序。这种设计背后的基本原理是将一些繁重的处理功能卸载为后台异步操作。在这种情况下，发布者是服务器端实时 Web 服务方法，需要立即（< 1 秒）响应调用 Web 服务客户端，并且发布者在 MOM 主题上发出消息。订阅者包含在与发布者相同的 Web 应用程序中，并且订阅者使用消息异步处理复杂的稍微耗时（5-7 秒）的功能。通过这种设计，我们可以避免在应用服务器容器中生成新线程来处理繁重的复杂处理功能。

在这种情况下，如果消息发布者和消息订阅者包含在同一个 Web 服务器地址空间中，那么使用 MOM 服务器是否过大？根据我的阅读，MOM 技术主要用于应用程序间通信，并想检查是否可以使用 MOM 进行应用程序内通信。

让你知道你的想法。

谢谢，

4

1 回答 1

0

也许您不会认为这是一个很好的例子，但在 JEE 世界中，使用 JMS 进行应用程序内通信是很常见的。产生新线程被认为是一种不好的做法，消息驱动的 bean 使使用消息相对容易，并且您可以获得事务支持。像 GlassFish 这样的兼容应用程序服务器具有板载 JMS，因此消息的生产和消费不会像独立的 ActiveMQ 那样涉及套接字通信。但是有一个独立的 JMS 可能是有原因的，例如，如果有一个消费者集群并且您希望活动实例从失败的实例中接管工作......但是独立 JMS 服务器成为单点故障，现在你想要一个集群等等。

JMS 的一个重要特性是（可选的）消息持久性。您可能会担心长时间运行的任务由于某种原因而失败，并且客户端的请求会丢失。但是持久性消息的成本要高得多，因为它们会导致磁盘 IO。

根据您的描述，我可以看出 MOM 的通常特性（异步处理、保证交付、消息顺序）您只需要异步处理。因此，如果保证不重要，我会使用某种线程池。

于 2015-06-24T22:51:22.227 回答