Java JMS 有什么用？

what is JMS good for?

提问by Dónal

I'm looking for (simple) examples of problems for which JMS is a good solution, and also reasons why JMS is a good solution in these cases. In the past I've simply used the database as a means of passing messages from A to B when the message cannot necessarily be processed by B immediately.

我正在寻找 JMS 是一个很好的解决方案的（简单）问题示例，以及为什么 JMS 在这些情况下是一个很好的解决方案的原因。过去，当消息不一定由 B 立即处理时，我只是将数据库用作将消息从 A 传递到 B 的一种方式。

A hypothetical example of such a system is where all newly registered users should be sent a welcome e-mail within 24 hours of registration. For the sake of argument, assume the DB does not record the time when each user registered, but instead a reference (foreign key) to each new user is stored in the pending_email table. The e-mail sender job runs once every 24 hours, sends an e-mail to all the users in this table, then deletes all the pending_email records.

此类系统的一个假设示例是，所有新注册用户都应在注册后 24 小时内收到欢迎电子邮件。为了论证起见，假设 DB 没有记录每个用户注册的时间，而是在 pending_email 表中存储了对每个新用户的引用（外键）。电子邮件发件人作业每 24 小时运行一次，向该表中的所有用户发送一封电子邮件，然后删除所有 pending_email 记录。

This seems like the kind of problem for which JMS should be used, but it's not clear to me what benefit JMS would have over the approach I've described. One advantage of the DB approach is that the messages are persistent. I understand that JMS message queues can also be persisted, but in that case there seems to be little difference between JMS and the "database as message queue" approach I've described?

这似乎是应该使用 JMS 的那种问题，但我不清楚 JMS 比我描述的方法有什么好处。DB 方法的优点之一是消息是持久的。我知道 JMS 消息队列也可以持久化，但在这种情况下，JMS 和我描述的“数据库作为消息队列”方法之间似乎没有什么区别？

What am I missing? - Don

我错过了什么？- 大学教师

采纳答案by James Strachan

JMS and messaging is really about 2 totally different things.

JMS 和消息传递实际上是两个完全不同的东西。

• publish and subscribe (sending a message to as many consumers as are interested - a bit like sending an email to a mailing list, the sender does not need to know who is subscribed
• high performance reliable load balancing (message queues)

• 发布和订阅（向尽可能多的感兴趣的消费者发送消息 - 有点像向邮件列表发送电子邮件，发件人不需要知道谁订阅了
• 高性能可靠负载均衡（消息队列）

See more info on how a queue compares to a topic

查看有关队列如何与主题进行比较的更多信息

The case you are talking about is the second case, where yes you can use a database table to kinda simulate a message queue.

您正在谈论的情况是第二种情况，是的，您可以使用数据库表来模拟消息队列。

The main difference is a JMS message queue is a high performance highly concurrent load balancer designed for huge throughput; you can send usually tens of thousands of messages per second to many concurrent consumers in many processes and threads. The reason for this is that a message queue is basically highly asynchronous - a good JMS provider will stream messages ahead of time to each consumerso that there are thousands of messages available to be processed in RAM as soon as a consumer is available. This leads to massive throughtput and very low latency.

主要区别在于 JMS 消息队列是为大吞吐量设计的高性能高并发负载均衡器；您通常可以每秒向许多进程和线程中的许多并发消费者发送数万条消息。这样做的原因是消息队列基本上是高度异步的——一个好的 JMS 提供者会提前将消息流式传输到每个消费者，这样一旦消费者可用，就有数以千计的消息可以在 RAM 中进行处理。这导致了巨大的吞吐量和非常低的延迟。

e.g. imagine writing a web load balancer using a database table :)

例如，想象一下使用数据库表编写 Web 负载均衡器 :)

When using a database table, typically one thread tends to lock the whole table so you tend to get very low throughput when trying to implement a high performance load balancer.

使用数据库表时，通常一个线程倾向于锁定整个表，因此在尝试实现高性能负载平衡器时，您往往会获得非常低的吞吐量。

But like most middleware it all depends on what you need; if you've a low throughput system with only a few messages per second - feel free to use a database table as a queue. But if you need low latency and high throughput - then JMS queues are highly recommended.

但与大多数中间件一样，这一切都取决于您的需求；如果您有一个每秒只有几条消息的低吞吐量系统 - 可以随意使用数据库表作为队列。但是如果您需要低延迟和高吞吐量 - 那么强烈建议使用 JMS 队列。

回答by Guido

In my opinion JMS and other message-based systems are intended to solve problems that need:

在我看来，JMS 和其他基于消息的系统旨在解决需要：

• Asynchronouscommunications : An application need to notify another that an event has occurred with no need to wait for a response.
• Reliability. Ensure once-and-only-once message delivery. With your DB approach you have to "reinvent the wheel", specially if you have several clients reading the messages.
• Loose coupling. Not all systems can communicate using a database. So JMS is pretty good to be used in heterogeneous environments with decoupled systems that can communicate over system boundaries.

• 异步通信：应用程序需要通知另一个事件已经发生而无需等待响应。
• 可靠性。确保一次且仅一次的消息传递。使用您的数据库方法，您必须“重新发明轮子”，特别是如果您有多个客户端读取消息。
• 松耦合。并非所有系统都可以使用数据库进行通信。因此，JMS 非常适合在具有解耦系统的异构环境中使用，这些系统可以跨系统边界进行通信。

回答by sk.

The JMS implementation is "push", in the sense that you don't have to poll the queue to discover new messages, but you register a callback that gets called as soon as a new message arrives.

JMS 实现是“推送”，从某种意义上说，您不必轮询队列来发现新消息，而是注册一个回调，该回调在新消息到达时立即调用。

回答by carson

Guido has the full definition. From my experience all of these are important for a good fit.

Guido 有完整的定义。根据我的经验，所有这些对于合身都很重要。

One of the uses I've seen is for order distribution in warehouses. Imagine an office supply company that has a fair number of warehouses that supply large offices with office supplies. Those orders would come into a central location and then be batched up for the correct warehouse to distribute. The warehouses don't have or want high speed connections in most cases so the orders are pushed down to them over dialup modems and this is where asynchronous comes in. The phone lines are not really that important either so half the orders may get in and this is where reliability is important.

我见过的用途之一是用于仓库中的订单分配。想象一家办公用品公司，它拥有相当数量的仓库，为大型办公室提供办公用品。这些订单将进入一个中心位置，然后被分批到正确的仓库进行分配。在大多数情况下，仓库没有或不需要高速连接，因此订单通过拨号调制解调器向下推送给他们，这就是异步的用武之地。电话线也不是那么重要，所以一半的订单可能会进入并这就是可靠性很重要的地方。

回答by Ichorus

The 'database as message queue' solution may be heavy for the task. The JMS solution is less tightly coupled in that the message sender does not need to know anything about the recipient. This could be accomplished with some additional abstraction in the 'database as message queue' as well so it is not a huge win...Also, you can use the queue in a 'publish and subscribe' way which can be handy depending on what you are trying to accomplish. It is also a nice way to further decouple your components. If all of your communication is within one system and/or having a log that is immediately available to an application is very important, your method seems good. If you are communicating between separate systems JMS is a good choice.

“数据库作为消息队列”的解决方案对于该任务来说可能很繁重。JMS 解决方案的耦合度较低，因为消息发送者不需要了解有关接收者的任何信息。这也可以通过“数据库作为消息队列”中的一些额外抽象来完成，因此这不是一个巨大的胜利......此外，您可以以“发布和订阅”方式使用队列，这取决于什么很方便你正在努力完成。这也是进一步解耦组件的好方法。如果您的所有通信都在一个系统内和/或具有可立即用于应用程序的日志非常重要，那么您的方法似乎不错。如果您在不同的系统之间进行通信，JMS 是一个不错的选择。

回答by PEELY

The key advantage is decoupling unrelated systems rather than have them share comon databases or building custom services to pass data around.

关键优势是将不相关的系统解耦，而不是让它们共享公共数据库或构建自定义服务来传递数据。

Banks are a keen example, with intraday messaging being used to pass around live data changes as they happen. It's very easy for the source system to throw a message "over the wall"; the downside is there's very little in the way of contract between these systems, and you normally see hospitalisation being implemented on the consumer's side. It's almost too loosly coupled.

银行就是一个敏锐的例子，当数据发生变化时，日内消息被用来传递实时数据变化。源系统很容易“翻墙”抛出消息；缺点是这些系统之间的合同方式很少，您通常会看到住院治疗是在消费者方面实施的。它几乎太松耦合了。

Other advantages are down to the support for JMS out of the box for many application servers, etc. and all the tools around that: durability, monitoring, reporting and throttling.

其他优势归结为对许多应用程序服务器等的开箱即用的 JMS 支持，以及围绕它的所有工具：持久性、监控、报告和节流。

回答by james

to address the original comment. what was originally described is the gist of (point-to-point) JMS. the benefits of JMS are, however:

以解决原始评论。最初描述的是（点对点）JMS 的要点。然而，JMS 的好处是：

1. you don't need to write the code yourself (and possibly screw up the logic so that it's not quite as persistent as you think it is). also, third-party impl might be more scalable than simple database approach.

2. jms handles publish/subscribe, which is a bit more complicated that the point-to-point example you gave

3. you are not tied to a specific implementation, and can swap it out if your needs change in the future, w/out messing w/ your java code.

1. 您不需要自己编写代码（并且可能会搞砸逻辑，使其不像您想象的那样持久）。此外，第三方 impl 可能比简单的数据库方法更具可扩展性。

2. jms 处理发布/订阅，这比您给出的点对点示例要复杂一些

3. 您不受特定实现的束缚，如果您将来的需求发生变化，可以将其替换掉，而不会弄乱您的 Java 代码。

回答by Rejeev Divakaran

One advantage of JMS is to enable asynchronous processing which can by done by database solution as well. However following are some other benefit of JMS over database solution

JMS 的优势之一是启用异步处理，这也可以通过数据库解决方案来完成。但是，以下是 JMS 相对于数据库解决方案的其他一些好处

a) The consumer of the message can be in a remote location. Exposing database for remote access is dangerous. You can workaround this by providing additional service for reading messages from database, that requires more effort.

a) 消息的消费者可以在远程位置。为远程访问公开数据库是危险的。您可以通过提供从数据库读取消息的附加服务来解决此问题，这需要更多的努力。

b) In the case of database the message consumer has to poll the database for messages where as JMS provides callback when a message is arrived (as sk mentioned)

b) 在数据库的情况下，消息消费者必须轮询数据库中的消息，因为 JMS 在消息到达时提供回调（如 sk 所述）

c) Load balancing - if there are lot of messages coming it is easy to have pool of message processors in JMS.

c) 负载平衡 - 如果有大量消息传入，则很容易在 JMS 中拥有消息处理器池。

d) In general implementation via JMS will be simpler and take less effort than database route

d) 一般来说，通过 JMS 实现会比数据库路由更简单，更省力

回答by Cyberroadie

JMS in combination with JTA (Java Transaction API) and JPA (Java persistence API) can be very useful. With a simple annotation you can put several database actions + message sending/receiving in the same transaction. So if one of them fails everything gets rolled back using the same transaction mechanism.

JMS 与 JTA（Java 事务 API）和 JPA（Java 持久性 API）结合使用非常有用。通过一个简单的注释，您可以在同一个事务中放置多个数据库操作 + 消息发送/接收。因此，如果其中一个失败，一切都会使用相同的事务机制回滚。

回答by KennyG

There's a nice write-up with some examples here: http://www.winslam.com/laramee/jms/index.html

这里有一篇很好的文章和一些例子：http: //www.winslam.com/laramee/jms/index.html