java - EHCache:验证跨 JVM 的缓存等效性

Question

我有一个 EHcaches 的 JMS 复制拓扑与 Websphere MQ 的工作概念证明。

为了解释一下它是如何工作的，我运行了 2 个 JVM。当 JVM1 调用 EHCache 的 'put' 方法时，一个元素被放入缓存中，然后在 JVM2 中复制它(这是通过 EHCache 配置完成的)。

根据 EhCache 的文档，JMS 复制拓扑被认为是“弱一致性”，这意味着每个 JVM 的缓存节点与其余节点保持同步可能会出现问题。

有谁知道如何比较两个 JVM(缓存节点)以确保它们包含等效的缓存对象和其中的所有缓存元素？

Answer 1

看起来您确实以相当复杂的方式定义了问题。让我们尝试简化一下:

• 首先，您拥有类似分布式Map 的东西，因此无需比较JVM 或缓存​​节点
• 其次，您正在设计一种方法来验证/测试您的设置，以便您可以使用预定义的数据

假设我们有两个缓存节点和一些复制魔法(在您的情况下由 Ehcache 提供):

我们还可以生成一些测试数据(一组key:value)对。因此，测试 Replication magic 的最简单方法是将我们的数据导入 Node 1 并设计一个非常简单的工具来监控“Node 2”。

请注意，您已经预定义了测试数据，因此您知道 key 并且可以定期扫描 Node 2 以尝试获取关联值。收集延迟、错误等其他信息以简化进一步分析是个好主意。

解决类似问题我使用方便的可视化来进一步简化分析。这是初始设计(实体大小也被跟踪，因为可能存在一些相关性):

这种方法大大简化了监控，此外，它还允许调整系统，因为相关反馈始终可用。

我确实创建了一个模型实现来展示它的外观。基本上，测试逻辑可以描述如下:

1. 工具将数据导入节点 1
2. 复制逻辑开始复制数据
3. 对于每个已知的键，该工具都会尝试从 Node 2 中获取一个值。
4. 工具定期执行扫描，直到所有数据可用

在运行时它可能如下所示(请不要忘记使用模型系统):

我定义了一些合理的限制，因为复制过程实际上没有魔法，所以可能需要一些时间。

精心设计的测试数据会揭示许多隐藏的 secret 。