Java消息队列或阅读文件手动

我们有独立的Java实例程序处理的原始博客这样的：Java消息队列或阅读文件手动

jvm instance 1 read fileA --> process 
jvm instance 2 read fileA ---> process 
jvm instance 3 read fileA ---> process 
....

我觉得当JVM实例数量的增加，disk IO进程数“会增加。有一段时间，这个解决方案无法正常工作。

那么谁能告诉我另一种解决方案for reduce the disk IO。

我认为理想的是使用JMS服务器（如Apache ActiveMQ）来读取队列和进程中的商店文件。

有任何问题，如果我使用JMS？

请帮助我。

来源

2012-07-26 tnk_peka

我不认为添加队列会减少系统中的I/O数量。请问为什么你有越来越多的JVM实例（我假设它们在一台服务器上） – maasg 2012-07-26 09:05:10

每个jvm实例都是一个程序，它们负有完全分离的责任！所以我不想在这里使用多线程。你能给这个理想吗？ – 2012-07-26 09:10:33

我是否正确读取每个实例读取相同的'fileA'？或者这只是示例中的一个错字？ – maasg 2012-07-26 09:12:08

事件驱动的解决方案当然是一个很好的选择，所以JMS可能是一个很好的解决方案。

但是，您应该记住，如果您的消费者不能跟上制作人，并且您将使用持久传送，则邮件将存储在硬盘上，这会导致磁盘IO。但我认为这不会成为一个问题，因为您可以随时增加并发消费者数量，甚至可以使用群集（例如，使用ActiveMQ进行配置非常简单）以跟上负载。总的来说，我认为JMS将是您的问题的一个很好的解决方案，因为您不需要主动轮询文件系统以进行更改，并且可以轻松扩展您的处理应用程序。

如果您对融合主题感兴趣，您可以访问enterprise integration site并阅读Gregor Hohpe和Bobby Woolf关于此主题的极佳书籍。你可以在提到的网站找到它的链接。在这里你会发现两种方法的所有优缺点，并熟悉其他可用的方法。反正消息传递绝对是一个很好的方式。

您可能会考虑使用camel framework作为提到那里模式的实现。

来源

2012-07-26 09:29:52

好吧，我想知道在处理JMS或任何其他解决方案之前，'流程'正在做什么。从目前来看，它像一个轻量级的生产者/消费者线程模型“闻起来”可以解决手头的问题。 – maasg 2012-07-26 10:18:55

@maasg你是完全正确的。但我认为，如果当前的解决方案使用多个jvm实例，则他们使用大量内存进行处理，因为这是处理日志gc停止世界暂停的常用方法（另一个解决方案是使用好的垃圾回收器）。因此，我认为这不是一种选择，他们正在寻找真正可扩展的东西。 JMS是可扩展性的绝佳选择。但是你肯定是正确的，在这个特例中关于处理器的知识会非常有用。 – 2012-07-26 11:11:52

事实上，在一个系统上使用几个JVM的原因可能很少，但是这个评论让我认为通过设计更改可能会有更好的解决方案（并且不会在中间件中解决问题时使用中间件来扩展系统）：“每个jvm实例都是一个程序，具有完全分离的责任！所以我不想在这里使用多线程” - 无论如何，看起来像OP不感兴趣。 – maasg 2012-07-27 08:54:11

Java消息队列或阅读文件手动

回答

相关问题