什么架构?跨集群分发内容构建

老实说,我会重新考虑你的方法,我会告诉你原因。

我在分布式大容量系统(特别是金融交易)和您的解决方案上做了大量的工作——如果容量足够大(我假设它足够大,或者您不会考虑使用集群解决方案;这些天,您可以从一个现成的设备中获得大量的电能)——那么您将通过远程呼叫自杀。S(即从另一个节点调用数据)。

我将在这里讨论Tangosol/Oracle的一致性,因为这是我最有经验的,尽管Terracotta将支持其中的一些或大部分功能,并且是免费的。

在一致性方面,您拥有的是一个分区缓存,如果您拥有 n 节点,每个节点都拥有 1/n 总数据的。通常,您至少有一个级别的冗余,并且冗余分布尽可能均匀,以便彼此之间 N-1 节点拥有 1/n-1 备份节点的。

这种解决方案的思想是尝试确保尽可能多的缓存命中是本地的(到同一个集群节点)。另外,对于分区缓存,写操作也相对比较特殊(而且对于每个缓存条目,备份节点越多,写操作就越昂贵),尽管写操作隐藏缓存可以将这一点最小化,但读操作也相当便宜(这正是您所需要的)。

所以你的解决方案会确保 每一个 缓存命中将到达远程节点。

另外,考虑到生成内容无疑比提供内容要贵得多,我假设这就是为什么您提出这个想法的原因,因为这样您可以拥有比服务器更多的内容生成器。这是更分层的方法,我将其描述为水平切片。

如果您可以垂直分割应用程序,那么您将获得更好的可伸缩性。我的意思是每个节点负责存储、生成和服务所有内容的一个子集。这有效地消除了代码间通信(不包括备份),并允许您通过为每个节点提供不同大小的内容子集来调整解决方案。

理想情况下,Web服务器应该可以复制您为数据分区选择的任何方案,这样它就可以准确地知道要访问哪个节点来获取相关数据。

现在,你可能有其他的理由按照你的建议去做,但我只能在现有信息的背景下回答这个问题。

我也会指给你一个 summary of grid/cluster technologies for Java 我写信是为了回答另一个问题。

你可能想试试 Hazelcast . 它是开放源码、对等机、分布式/分区映射和支持逐出的队列。进口一个单罐,你很好去!超级简单。

如果内容构建可以并行化(Builder 1执行1..1000,Builder 2执行1001..2000),则可以创建一个配置文件来传递此信息。ContentBuilder将负责监视其区域是否过期。

如果这是不可能的,那么您需要某种管理器来协调内容构建。这个管理器还可以扮演负载均衡器的角色。管理器可以与ContentBuilder捆绑在一起,也可以是它自己的节点。

我认为分布式缓存和JMS消息传递的思想是很好的。

听起来您需要某种形式的分布式缓存、分布式锁定和消息传递。

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 .

我同意克莱图斯的观点——如果你需要高性能,你需要考虑分区,但是与大多数解决方案不同,赤土在你需要之前不需要分区就可以很好地工作,然后当你应用分区时,它会根据你的分区算法来划分工作。