为什么我应该使用JMS而不是RMI+Queue？

Question

目前，我正在使用RMI或hessian library (通过LinkedBlockingQueue)在服务器和客户端之间进行通信。现在我读到了关于JMS的文章，它也可以用于这一领域。这是正确的吗？如果是，你介意给我一个简单的优势/劣势清单吗?因为这似乎是一个相当复杂和“成熟的企业”领域。

有什么福利待遇？与RMI+Queue相比，它的性能如何？JMS能打败RMI+Queue吗？

PS:我知道有similar questions，但我希望有RMI+Queue的比较。

Answer 1

一个简化的比较是(不是特定于JMS，更像是与MQ的比较)……

1. 自动重试

如果您是对服务器执行RMI的客户端，并且由于某种原因RMI失败，则您必须自己重试。如果您使用JMS，并且您是客户端，则只需发送JMS消息。当无法连接到服务器时，您的消息将被存储，然后在服务器重新启动时发送。

• 持久队列

由于您使用的是LinkedBlockingQueue，因此内存中可以有一个有界队列，也可以有一个无界队列。前者将开始捕获线程，一旦队列已满，最终将在高负载下失败。后者最终会抛出OutOfMemoryError。如果您使用JMS，它可以自动开始将消息“持久化”到“持久化存储”。通常的“持久存储”是DB，它的容量通常比内存中的队列大得多。当然，内存中队列的内容会在服务器宕机等情况下丢失，而在JMS中，您可以选择在此类事件中幸存下来的持久消息/持久消息。这也允许你拥有集群，这对于企业程序也是非常重要的…

• 抽象

您将使用一个标准化的API (好的，您在RMI中也有协议，但是如果您想要的是传递消息，MQ提供了比RMI+内存中队列多得多的高级抽象)。这意味着，您可以使用JMS的未来实现。也许不需要DB来提供持久性和持久性，比现在的实现更具伸缩性等等。或者，由于标准化，您可以将相同的消息发送到完全不同的服务。基本上，更高的抽象可以为您提供灵活性，而RMI+内存队列则不能。

不久前，我与一家大公司合作，该公司希望使用他们的内部框架来集成我们的东西。当时我们还没有使用MQ。我们要求他们使用我们自己的基于RMI的异步协议。相信我，我们对这个决定感到非常非常遗憾...

Answer 2

其他答案涵盖了JMS的许多方面，但我觉得需要更多强调一个非常重要的方面，即JMS以事务方式支持多个并发使用者的事实。对我来说，这就是杀手级特性。

1. 您可以很容易地构建一个只有一个消费者和生产者的非事务性系统。
2. 你也可以通过更多的工作使它(或多或少)成为事务性的。
3. 类似地，您可以相对容易地添加对多个生产者和单个消费者的支持，例如，如果您使用事务性数据库来存储消息。
4. ，但是要拥有多个并发的消费者并让消息消费成为事务性的变得非常困难。这基本上需要一个非平凡的锁定方案，即使使用事务性数据库，这项任务也不容易。

然而，当我们谈到JMS scalability，时，我们谈到的是:应用程序的能力。服务器来添加/删除消费者/生产者来管理负载。

JMS的其他优点是服务质量和管理，例如重发尝试、死消息队列、监控等。

如果你不是真的需要它，一种稍微简单一点的解决方案可能行得通。您还可以看到我的另一个答案，其中包含一个类似的问题：Why choosing JMS for asynchronous solution ?

Answer 3

您的解决方案中的“队列”部分使用了什么？你自己的代码？

JMS只是某个供应商的队列系统之上的API，但它包含了远程处理方面。因此，从客户端的角度来看，您只需将一条消息放在队列中(如果您正在执行pub sub，则将其放在主题中)，然后将其抛诸脑后。基础设施将其传递给监听器。

我认为JMS的大部分功能都来自队列基础设施的实现质量，而不是API本身，这很简单。

简单的RMI不能很好地扩展或处理可靠性问题，一个好的排队系统可以同时具有可扩展性和弹性。

我认为可以公平地说，JMS和Java的其余部分旨在使您的应用程序成为企业级质量。最初，我认为Java EE overal很复杂，尽管我认为JMS是比较简单的方法之一。今天，我不确定编写RMI +您自己的队列是否比仅仅使用JMS更容易。

可能一个显着的区别是，使用JMS在很大程度上假设您已经有了一些基础设施，比如App Server。