Terracotta 是否使 JMS 成为不需要的层？
我们目前正在编写一个应用程序，IT 部门已经为其购买了硬件。 他们的方法是购买大型硬件供我们部署。 为了增加更多的处理能力，他们计划添加具有相同软件的额外服务器。 为了适应这一设计，我们使用 Terracotta 来提供运行多个 JVM 的能力，就好像它是一个大的 JVM 一样。 不管这是否是明智的选择（我仍然不相信），这就是我正在处理的情况。
无论如何，我们有一部分应用程序使用标准生产者/消费者类型队列。 借助 Terracotta，我们能够创建可与多个 JVM 一起使用的单个队列。 这非常光滑并且效果很好。
但现在，我们正在寻找运行异步进程的更多机会。 为了使我们所有的排队逻辑更加一致，我们正在考虑使用 JMS 来抽象出公共逻辑。 由于我们不打算使用 JMS 作为远程队列（至少在可预见的将来），我想知道 JMS 是否只是增加了不必要的复杂性。
有什么建议或想法吗？ 我们应该继续将队列构建为并发结构，还是将它们视为单独的、潜在的远程对象？
We're currently writing an application for which IT has already purchased hardware for. Their approach was to buy big hardware on which we would deploy. In order to add more processing, they plan on adding additional servers with identical software. In order to accomodate this design, we are using Terracotta to provide the ability to run multiple JVM's as though it was one large one. Regardless of whether or not this is a wise way to go (which I'm still not convinced), this is the situation I'm dealing with.
Anyway, we have a portion of the application that uses a standard producer/consumer type queue. With Terracotta, we're able to create a single queue that works with multiple JVM's. This is pretty slick and it works well.
But now, we are finding additional opportunities to run asynchronuous processes. To make all of our queuing logic more consistent, we're considering using JMS to abstract out common logic. Since we're not going to use JMS as a remote queue (at least for the foreseeable future), I'm wondering if JMS is just adding unneeded complexity.
Any suggestions or thoughts? Should we just continue to build queues as concurrent structures, or treat them as separate, potentially remote objects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的一位同事一直在使用 Mule，它允许您定义队列，这些队列可能是JVM 内部或之间的队列。
我同意 krosenwald 的观点：目前尚不清楚 JMS 将在您的案例中添加什么，除非有一个远离 Terracotta 的总体计划（或者至少可以选择）。
A colleague of mine has been using Mule, which allows you to define queues which may be intra- or inter-JVM queues.
I agree with krosenwald: it's not clear what JMS would be adding in your case, unless there is a general plan to either move away from Terracotta (or at least have the option to).
消息队列本质上只是具有一些奇特选项的队列数据结构。 如果您的项目与大多数其他项目一样，则您没有使用任何使 JMS 不同于任何旧 队列 实现，特别是因为 Terracotta 正在处理持久性和分发。
因此，JMS 可能只是增加了应用程序的复杂性，而这正是 JMS 所擅长的。 像所有不必要的复杂性驱动因素一样，摆脱它。 如果您出于一个或多个原因决定使用 JMS，那就这么做吧。
A message queue is essentially just Queue data-structure that has some fancy options. If your project is like most other projects, you're not using any of the JMS features that make JMS different from any old Queue implementation, especially since Terracotta is handling persistence and distribution.
So JMS is probably just adding complexity to your application, which is something JMS is quite good at. Like all unneeded drivers of complexity, get rid of it. If you ever decide to use JMS for one or more reasons, do it then.
我没有使用过 Terracotta，但我们正在使用与其非常相似的分布式缓存产品。 我们的架构听起来也与您的架构相似。 生产者和消费者都坐在同一个缓存上，并使用缓存子系统共享数据。
虽然我同意原则上现在添加 JMS 对您来说可能是不必要的复杂性，但我们发现，虽然分布式缓存很巧妙，但它并不是消息传递机制的最佳实现。 虽然可以创建相同的语义，但一些小细节会导致问题（例如消费者的负载平衡，这可能需要与分布式缓存进行额外的同步，但可以自然地与 JMS 配合使用。）
如果您认为未来的用例需要更多的发布，子语义与持久性等，您可能想开始考虑 JMS。 另外，请考虑关注点分离。 您正在使用 Terracotta 来分发数据（这就是它的设计目的）。 您还会使用它来分发控制指令（通过消息语义可以做得更好）吗？
I haven't used Terracotta but we are using a distributed caching product very similar to it. Our architecture also sounds similar to what you have. With both producers and consumers sitting on the same cache and sharing data using the caching subsystem.
While I agree on principal that adding JMS now might be an unneccesary complexity for you, we have found that, while slick, the distributed cache is not the best implementation of a messaging mechanism. While the same sematics can be created, some small details cause issues (such as load-balancing for consumers, which might require additional synronisation with a distributed cache, but works naturally with JMS.)
If you think your future use cases require more pub-sub semantics with persistence etc, you might want to start thinking about JMS. Also, consider separation of concerns. You are using Terracotta to distribute data (which is what it is designed to do). Will you also use it to distribute control instructions (which is done better with messaing semantics)?