消息传递（例如 JMS）何时可以替代多线程？
我正在开发一个数据处理应用程序，其中通过将多个工作单元放在消息驱动 Bean (MDB) 的多个实例侦听的消息队列上来实现并发性。除了以这种方式实现并发之外，我们没有任何特定原因使用消息传递基础设施和 MDB。
这让我思考为什么使用多线程无法实现相同的效果。
所以我的问题是，在什么情况下可以使用异步消息传递（例如 JMS）作为多线程的替代方法来实现并发？使用一种方法相对于另一种方法有哪些优点/缺点？
I work on a data processing application in which concurrency is achieved by putting several units of work on a message queue that multiple instances of a message driven bean (MDB) listen to. Other than achieving concurrency in this manner, we do not have any specific reason to use the messaging infrastructure and MDBs.
This led me to think why the same could not have been achieved using multiple threads.
So my question is, in what situations can asynchronous messaging (e.g. JMS) be used as an alternative to mutithreading as a means to achieve concurrency ? What are some advantages/disadvantages of using one approach over another.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
性能方面的多线程应该比任何消息传递更快，因为您添加了一个带有消息传递的附加网络层。
应用程序级消息传递可帮助您避免锁定和数据共享问题，因为没有公共对象。
从扩展的角度来看，消息传递要好得多，因为您可以通过配置消息服务在多个服务器上配置更多节点，而无需更改应用程序。
Performance-wise multi-threading should be faster than any messaging, because you add an additional network layer with messaging.
Application-wise messaging helps you to avoid locking and data sharing issues as there is no common object.
From a scaling perspective messaging is a lot better as you can configure just more nodes on several server by configuring the message service instead of changing the application.
消息传递可以大大减少多线程应用程序中的错误数量，因为它降低了数据争用的风险。它还简化了添加新线程的过程，而无需更改应用程序的其余部分。
虽然我认为 JMS 在这里有点被误用了。 java.util.concurrent 的线程安全队列和库（例如 jetlang）可能会为您提供更好的性能。
Messaging can reduce number of errors in multithreaded applications greatly, since it reduces risk of data races. It also simplifies adding new threads without changing the rest of app.
Although I think JMS is slightly misused here. java.util.concurrent's thread-safe queues and libraries like jetlang may provide you better performance.
使用多线程，您可以通过共享CPU核心来实现并发。但如果您使用 JMS，则可以平衡负载并将任务委托给其他系统。
例如，假设您的应用程序要求在完成特定任务时发送电子邮件。并且您想同时发送电子邮件。您可以拉出一个线程并异步处理它。或者您可以使用 JMS 将邮件发送任务委托给其他系统。 jms 中不能配置接收器线程。多个节点还可以监听相同的 JMS 队列来平衡负载。您还可以根据应用程序使用其他应用程序，例如持久队列、事务管理队列。
简而言之，JMS 能否更好地替代多线程取决于应用程序架构
Using multi-threading you can achieve concurrency by sharing core of CPU. But if you use JMS instead you can balance the load and can delegate the task to other system.
e.g. Suppose your application demands to send email on completion of certain task. And you want to send email concurrently. Either you can pull a thread and process it asynchronously. Or you can delegate this task of mail sending to other system using JMS. No of receiver threads can be configurable in jms. Also multiple nodes can listen to same JMS queue which balance the loads. And you can use further applications like persistent queue, transaction managed queue as per application.
In simple words, JMS can be better alternative to multi-threading depends on application architecture
它不能用作多线程的替代品，它是实现多线程的一种方式。这里有三种基本的解决方案：
接收数据是这里的关键，因为如果没有某种形式的多线程/多处理，实际上就没有办法做到这一点，否则您一次只能处理一个请求。在不使用多线程的情况下发送数据要可行得多，但您只是将处理这些消息的责任真正推给了外部系统。所以它不是多线程的替代品。
在使用消息驱动 bean 的情况下，容器正在为您创建和管理线程，因此它不是多线程的替代方案，您只是使用其他人的实现。
It can't be used as an alternative to multithreading, it is a way of of implementing multithreading. There are three basic kinds of solutions here:
Receiving data is the kicker here because there's really no way of doing that without some form of multithreading/multiprocessing otherwise you'll only be processing one request at a time. Sending data without multithreading is much more viable but there you're only really pushing the responsibility for dealing with those messages to an external system. So it's not an alternative to multithreading.
In your case with message driven beans, the container is creating and managing threads for you so it's not an alternative to multithreading, you're simply using someone else's implementation.
我认为还有两个额外的好处没有被提及：交易和持久性。
虽然这不是必需的，而且通常不是默认配置，但 JMS 提供程序可以配置为持久保存消息，并且只需很少或无需更改代码即可参与 XA 事务。
There are two additional bonuses that I don't think has been mentioned: Transactions and durability.
While it isn't required and quite often isn't the default configuration, JMS providers can be configured to persist the messages and also to participate in a XA transaction with little or no code changes.
实际上，在 EJB 容器中，没有其他选择，因为不允许您在 EJB 容器中创建自己的线程。 JMS 正在为您完成所有这些工作，但代价是通过队列处理器运行它。您还可以创建一个 Java 连接器，它与容器有更密切的关系（因此可以有线程），但需要做更多的工作。
如果使用 JMS 队列的开销不会对性能产生影响，那么它是最简单的解决方案。
In an EJB container, actually, there is no alternative, since you're not allowed to create your own threads in an EJB container. JMS is doing all of that work for you, at a cost of running it through the queue processor. You could also create a Java Connector, which has a more intimate relationship with the container (and thus, can have threads), but it's a lot more work.
If the overhead of using the JMS queue isn't having a performance impact, then it's the easiest solution.