javaee解决方案中消息传递的必要性

考虑一个在web上搜索特定数据的工作进程。需要另一个过程来索引第一个过程的结果，以供以后使用。索引部分涉及以特定方式将原始数据（搜索结果）写入大型分布式HBase存储库。我无法判断这两个过程的速度。我们可能会遇到这样一种情况，其中一个系统暂时关闭，需要在唤醒时执行任务。我正在使用JavaEE。目前，这就是我想要实现的方式

第一个进程将其搜索结果存储在MySQL数据库中，并发送一条消息，其中包含它放入表中的新行的ID

MOM唤醒第二个进程以使用存储在MySQL数据库中的新原始数据

第二个进程在完成对真实数据库（HBase）中的数据的索引后清除MySQL表

---

我需要专家对我的设计提出意见，以验证其适当性。例如，如果第二个进程连续轮询表以查看是否有新记录，该怎么办？我使用的是正确的技术还是过度使用？我应该简化我的设计还是遗漏了什么？如果我的解决方案是合适的，那么在实施过程中我是否应该记住什么？提前感谢。

如果可能的话，我会坚持使用更简单的设计，放弃MySQL临时表，坚持使用JMS

所以，像这样的东西可以做到：

[P1]将搜索结果发送到某个JMS队列“INDEX.queue”

[P2]简单地异步读取队列“INDEX.queue”的消息，并根据消息负载中的搜索结果生成搜索索引

---

消息传递可以帮助您完成这些任务，轮询数据库表几乎是一样的，但更为棘手，因此，当您有一个为这项任务设计的持久性事务性MOM时，为什么要重新设计轮子呢。

谢谢。如果消息越来越大，会发生什么？考虑队列中的数十个消息，每个消息的大小为10-50MB。在这种情况下使用临时表更好吗，还是根本没有什么区别？当然。大小确实很重要，但我使用的是GlassFish v3，它可以很容易地配置为使用数据库来存储消息，正如您刚才所说的。你的建议真的很有帮助。很好！也就是说，从性能角度来看，我不确定使用数据库作为消息存储是否是所有情况下的最佳解决方案。但这取决于你认为什么是最重要的。我不知道Glassfish/OpenMQ的性能细节。