Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/java/401.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java 什么建筑?跨集群分发内容构建_Java_Architecture_Cluster Computing - Fatal编程技术网

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

Java 什么建筑?跨集群分发内容构建,java,architecture,cluster-computing,Java,Architecture,Cluster Computing,我正在构建一个内容服务应用程序,它由两种类型的节点组成,即ContentServers和ContentBuilder 其理念是始终提供新鲜内容。如果内容是最近创建的,即Content.buildTime

我正在构建一个内容服务应用程序,它由两种类型的节点组成,即ContentServers和ContentBuilder

其理念是始终提供新鲜内容。如果内容是最近创建的,即Content.buildTime 要求:

*ContentServers只需查找内容并提供服务(例如,从分布式缓存或类似缓存),不需要等待构建任何内容,除非第一次请求每个内容项

*ContentBuilder应该是负载平衡的,应该在内容过期之前重建内容,应该只构建实际被请求的内容。所有ContentServer都应该能够快速检索构建的内容

我应该使用什么架构?我目前正在考虑一个分布式缓存(EHCache可能)来保存构建的内容和消息队列(JMS/ActudiMQ可能),以将内容请求转播给建设者,尽管我会考虑任何其他选项/建议。我如何确保ContentBuilders不会在同一时间构建相同的内容,而只在内容接近到期时构建内容


谢谢。

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

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


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

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

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


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

老实说,我会重新思考您的方法,并告诉您原因

我在分布式大容量系统(特别是金融交易)和您的解决方案方面做了很多工作——如果容量足够大的话(我假设是这样,否则您就不会考虑集群解决方案;现在您可以从一个现成的机箱中获得大量的电力)--然后,您将通过远程调用(即从另一个节点调用数据)自杀

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

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

这种解决方案的想法是尝试并确保尽可能多的缓存命中是本地的(对于同一集群节点)。另外,特别是对于分区缓存,写操作的开销相对较大(每个缓存项的备份节点越多,成本就越高)——尽管写后缓存可以最大限度地减少这一点——而且读操作也相当便宜(这正是您所希望的)

因此,您的解决方案将确保每次缓存命中都将被发送到远程节点

还认为生成内容无疑比服务内容要昂贵得多,我想这就是为什么你想出这个想法,因为这样你可以拥有比服务器更多的内容生成器。这是一种更分层的方法,我将其描述为水平切片

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

理想情况下,无论您选择何种数据分区方案,Web服务器都应该可以复制,以便它准确地知道要点击哪个节点获取相关数据

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


我还将向您指出我在回答另一个问题时写的一篇文章。

老实说,我会重新思考您的方法,并告诉您原因

我在分布式大容量系统(特别是金融交易)和您的解决方案方面做了很多工作——如果容量足够大的话(我假设是这样,否则您就不会考虑集群解决方案;现在您可以从一个现成的机箱中获得大量的电力)--然后,您将通过远程调用(即从另一个节点调用数据)自杀

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

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

这种解决方案的想法是尝试确保尽可能多的缓存命中是本地的(对于同一个cl)