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