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

时间:2015-03-25 16:07:55

标签: java ehcache consistency

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

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

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

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

1 个答案:

答案 0 :(得分:3)

看起来你已经以非常复杂的方式定义了问题。我们试着简化一下:

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

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

enter image description here

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

请注意,您预先定义了测试数据,因此您知道密钥并可以定期扫描Node 2以获取相关值。收集延迟,错误等其他信息以简化进一步分析是个好主意。

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

enter image description here

这种方法简化了监控,而且,它允许调整系统,因为总是有相关的反馈。

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

  1. 工具会将数据导入Node 1
  2. 复制逻辑开始复制数据
  3. 对于每个已知密钥,该工具都会尝试从Node 2获取值。
  4. 工具定期执行扫描,直到所有数据都可用
  5. 在运行时,它可能如下所示(请不要忘记使用模型系统):

    enter image description here

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

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