什么是JMS有用？ [英] what is JMS good for?

问题描述

我正在寻找JMS是一个很好的解决方案的问题的简单例子，也是JMS在这些情况下是一个很好的解决方案的原因。在过去，我只是简单地使用数据库作为将消息从A传递到B的方法，当消息不一定立即被B处理时。

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.

一个假设的例子这样的系统是所有新注册用户应在注册后24小时内收到欢迎电子邮件的地方。为了便于论证，假设DB不记录每个用户注册的时间，而是将每个新用户的引用（外键）存储在pending_email表中。电子邮件发件人作业每24小时运行一次，向该表中的所有用户发送电子邮件，然后删除所有pending_email记录。

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.

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

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?

我错过了什么？
- Don

What am I missing? - Don

推荐答案

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

JMS and messaging is really about 2 totally different things.

• 发布和订阅（向感兴趣的消费者发送消息 - 有点像向邮件列表发送电子邮件，发件人不需要知道谁订阅了


• 高性能可靠负载平衡（消息队列）

查看有关队列如何与主题进行比较

你所说的是第二种情况，你可以使用数据库表来模拟消息队列。

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

主要区别在于JMS消息队列是为高吞吐量而设计的高性能高度并发负载平衡器;您可以在许多进程和线程中每秒向许多并发消费者发送通常数万条消息。因此，消息队列基本上是高度异步的 - good JMS提供程序将提前将消息流式传输给每个消费者，以便在消费者可用时，有数千条消息可在RAM中处理。这会导致大量的吞吐量和非常低的延迟。

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 consumer so 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.

例如。想象一下使用数据库表编写Web负载均衡器：）

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

使用数据库表时，通常一个线程会锁定整个表，因此您的吞吐量往往很低当试图实现高性能负载均衡器时。

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.

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

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有用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！