我们目前正在编写一个应用程序，IT 部门已经为其购买了硬件。他们的方法是购买我们将在其上部署的大型硬件。为了增加处理能力，他们计划增加具有相同软件的额外服务器。为了适应这种设计，我们使用 Terracotta 来提供运行多个 JVM 的能力，就像它是一个大的 JVM 一样。不管这是否是一个明智的做法(我仍然不相信)，这就是我正在处理的情况。
无论如何，我们有一部分应用程序使用标准的生产者/消费者类型队列。使用 Terracotta，我们能够创建与多个 JVM 一起工作的单个队列。这非常巧妙，而且效果很好。
但是现在，我们正在寻找运行异步进程的更多机会。为了使我们所有的排队逻辑更加一致，我们正在考虑使用 JMS 来抽象出通用逻辑。由于我们不会将 JMS 用作远程队列(至少在可预见的 future )，我想知道 JMS 是否只是在增加不必要的复杂性。
有什么建议或想法吗？我们应该继续将队列构建为并发结构，还是将它们视为独立的、潜在的远程对象？
最佳答案
消息队列本质上只是具有一些奇特选项的队列数据结构。如果您的项目与大多数其他项目一样，则您没有使用任何使 JMS 不同于任何旧的 JMS 的功能 Queue实现，特别是因为 Terracotta 正在处理持久性和分布。
因此 JMS 可能只是增加了您的应用程序的复杂性，而这是 JMS 非常擅长的事情。像所有不必要的复杂性驱动因素一样，摆脱它。如果您出于一个或多个原因决定使用 JMS，那就去做吧。
关于java - Terracotta 是否使 JMS 成为一个不需要的层？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1258376/