我们有一个相当复杂的 Java EE 应用程序（Java 后端 + GRails 前端通过 Spring HTTP Invoker 进行通信），其中包含大量可怕的遗留代码。目前它在 Jboss 中运行（稍后将迁移到 Tomcat）。
为了使其更可靠并提高性能，我们需要使其可集群化。
问题是应用程序目前有许多对需要复制的整个业务至关重要的深层内存结构（例如，在另一个 ConcurrentHashMap 内部的 ConcurrentHashMap 内部的 HashMap 内部的列表内部的域对象）。
正如我所说，有很多遗留代码，我们不能全部重做。
目前我正在使用 EHCache，但显然没有成功 - 缓存对象内部的更改不会被复制。
Terracotta DSO 看起来像是我们应该研究的东西，但它是最终的解决方案，我只是不想介绍这种激进的解决方案，而我们希望以更通用的方式解决它。
实际上，这是大多数兑现解决方案的典型问题 - 使用深度内存结构并且没有简单的方法来处理这个问题。
因此，例如让我们以企业网格 - gigaspaces - 这就是它的完成方式http://www.gigaspaces.com/wiki/display/XAP8/Modeling+your+data
这真的是解释周围的事情：
什么时候应该嵌入对象？您已经知道嵌入相关对象不是一个好习惯。但即使有很好的嵌入相关对象的案例（有时以数据重复为代价），您仍然应该注意以下几点：
嵌入意味着没有直接访问：当一个实体嵌入到另一个实体中时，您不能直接对其应用 CRUD 操作。相反，您需要通过常规查询从空间中获取其根父实体，然后向下导航对象图，直到获得所需的实体。这不仅仅是方便的问题，它还具有性能影响：每当您想对嵌入式实体执行 CRUD 操作时，您首先读取整个图，然后（如果您还需要更新它）将整个对象图写回到空间。另一方面，使用 GigaSpaces 非嵌入式关系意味着您需要在代码中自己管理关系。选择嵌入关系的拇指规则 当实体仅对其包含对象的上下文有意义时嵌入。例如，在宠物诊所应用程序中 - 宠物只有在拥有所有者时才有意义。在这个特定的应用程序中，如果没有所有者，宠物本身是没有意义的。没有将宠物从所有者转移到所有者或在没有所有者的情况下将宠物接纳为兽医的业务场景。嵌入有时可能意味着复制您的数据。例如，如果您想引用 Pet 和 Vet 类中的某个访问，则需要有重复的访问条目。所以让我们来看看重复：重复意味着更喜欢可伸缩性而不是占用空间 - 重复的原因是为了避免集群范围的事务，并且在许多情况下，这是以可伸缩方式划分对象的唯一方法。复制意味着更高的内存消耗：虽然今天内存被认为是一种商品和低成本，复制要付出更大的代价——你可能有两个包含相同数据的空间对象。重复意味着更宽松的一致性。例如，当您向宠物和兽医添加访问时，您需要同时更新它们。您可以在一个（可能是分布式的）事务中执行此操作，也可以在两个单独的事务中执行此操作，这样可以更好地扩展但不太一致。这对于许多类型的应用程序（例如社交网络）来说可能就足够了，在这些应用程序中丢失帖子虽然不受欢迎，但不会造成重大损害。相比之下，这对于应考虑每项操作的金融应用程序来说是不可行的。您可以在一个（可能是分布式的）事务中执行此操作，也可以在两个单独的事务中执行此操作，这样可以更好地扩展但不太一致。这对于许多类型的应用程序（例如社交网络）来说可能就足够了，在这些应用程序中丢失帖子虽然不受欢迎，但不会造成重大损害。相比之下，这对于应考虑每项操作的金融应用程序来说是不可行的。您可以在一个（可能是分布式的）事务中执行此操作，也可以在两个单独的事务中执行此操作，这样可以更好地扩展但不太一致。这对于许多类型的应用程序（例如社交网络）来说可能就足够了，在这些应用程序中丢失帖子虽然不受欢迎，但不会造成重大损害。相比之下，这对于应考虑每项操作的金融应用程序来说是不可行的。
在hazelcast 中，您有一个与 gigaspaces 不同的数据亲和性概念http://www.hazelcast.com/docs/1.9.4/manual/multi_html/ch03.html 。
我的意思是没有简单的解决方案，我想您无论如何都需要重新设计您的模型（无论这是否是连贯性、gigaspaces、ehcache、hazelcast 都无关紧要）。