EHCache：验证跨 JVM 的缓存等效性

Question

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

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

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

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

Answer 1

看起来您确实以非常复杂的方式定义了问题。让我们试着简化一下：

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

假设我们有两个缓存节点和一些 Replication magic（在您的情况下由 Ehcache 提供）：

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

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

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

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

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

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

在运行时可能如下所示（请不要忘记使用了模型系统）：

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

精心设计的测试数据将揭示许多隐藏的秘密。