我正在构建一个内容服务应用程序，该应用程序由两种类型的节点（ContentServers 和 ContentBuilders）组成的集群。
我们的想法是始终提供新鲜的内容。如果内容是最近构建的，则内容是新鲜的，即 Content.buildTime < MAX_AGE。
要求：
*ContentServers 只需要查找内容并提供它（例如从分布式缓存或类似的），除了对每个内容项的第一次请求外，无需等待任何内容的构建。
*ContentBuilders 应该是负载平衡的，应该在内容到期之前重建内容，应该只构建实际被请求的内容。构建的内容应该可以被所有 ContentServer 快速检索
我应该使用什么架构？我目前正在考虑一个分布式缓存（也许是 EhCache）来保存构建的内容和一个消息队列（也许是 JMS/ActiveMQ）来将内容请求中继给构建器，尽管我会考虑任何其他选项/建议。我如何确定 ContentBuilders 不会同时构建相同的东西，并且只会在内容接近到期时构建内容？
谢谢。
老实说，我会重新考虑你的方法，我会告诉你为什么。
我在分布式大容量系统（特别是金融交易）和您的解决方案上做了很多工作——如果容量足够高（我会假设它是这样，否则您不会考虑使用集群解决方案；您这些天可以从一个现成的盒子中获得大量的电力）——然后你会用远程调用杀死自己（即从另一个节点调用数据）。
我将在这里谈论 Tangosol/Oracle Coherence，因为这是我最有经验的，尽管 Terracotta 将支持其中的部分或大部分功能并且是免费的。
在 Coherence 术语中，您拥有的是分区缓存，如果您有n 个节点，则每个节点拥有总数据的1/n。通常，您具有至少一个级别的冗余，并且该冗余尽可能均匀地分布，因此其他n-1个节点中的每一个都拥有1/n-1个备份节点。
这种解决方案的想法是尝试确保尽可能多的缓存命中是本地的（对于同一个集群节点）。此外，特别是分区缓存，写入相对更容易（并且每个缓存条目拥有的备份节点越多，成本就会越高）——尽管后写缓存可以最大限度地减少这一点——并且读取相当便宜（这就是你想出你的要求）。
因此，您的解决方案将确保每次缓存命中都将到达远程节点。
还要考虑生成内容无疑比提供内容要昂贵得多，我认为这就是您提出这个想法的原因，因为这样您就可以拥有比服务器更多的内容生成器。这是一种更分层的方法，我将其描述为水平切片。
如果您可以垂直分割您的应用程序，您将获得更好的可伸缩性。我的意思是每个节点负责存储、生成和提供所有内容的子集。这有效地消除了节点间通信（不包括备份），并允许您通过简单地为每个节点提供不同大小的内容子集来调整解决方案。
理想情况下，您选择的任何数据分区方案都应该可以由您的 Web 服务器重现，这样它就可以准确地知道要访问哪个节点来获取相关数据。
现在您可能有其他理由按照您提议的方式进行操作，但我只能在可用信息的背景下回答这个问题。
我还将向您指出我为回答另一个问题而编写的 Java 网格/集群技术摘要。
您可能想尝试Hazelcast。它是开源的，peer2peer，分布式/分区映射和队列，支持驱逐。导入一个罐子，你很高兴！超级简单。
如果内容构建可以并行化（构建器 1 执行 1..1000，构建器 2 执行 1001..2000），那么您可以创建一个配置文件来传递此信息。ContentBuilder 将负责监控其区域是否过期。
如果这不可能，那么您需要某种经理来协调内容构建。该管理器也可以扮演负载均衡器的角色。管理器可以与 ContentBuilder 捆绑在一起，也可以是它自己的一个节点。
我认为分布式缓存和 JMS 消息传递的想法是好的。
听起来您需要某种形式的分布式缓存、分布式锁定和消息传递。
Terracotta 为您提供了这三者 - 分布式缓存、分布式锁定和消息传递，并且您的编程模型只是 Java（不需要 JMS）。
我在这里写了一篇关于如何确保缓存只填充其内容一次且仅一次的博客：什么是记忆器以及为什么要关心它。
我同意 Cletus - 如果您需要高性能，则需要考虑分区，但与大多数解决方案不同，Terracotta 无需分区即可正常工作，直到您需要它，然后当您应用分区时，它只会根据你的分区算法。