我有一个EHcaches概念的工作证明'使用Websphere MQ的JMS复制拓扑。
为了解释它是如何工作的,我有2个JVM正在运行。当JVM1调用EHCache时,放置'方法,将一个元素放入缓存中,然后在JVM2中复制(通过EHCache配置完成)。
根据EhCache的文档,JMS复制拓扑被认为是“弱一致性”,这意味着每个JVM的缓存节点可能与其余部分保持同步。
有没有人知道如何比较两个JVM(缓存节点)以确保它们包含等效的Cache对象和所有缓存元素?
答案 0 :(得分:3)
看起来你已经以非常复杂的方式定义了问题。我们试着简化一下:
Map
的内容,因此无需比较JVM或缓存节点假设我们有两个缓存节点和一些Replication magic
(在您的情况下由Ehcache提供):
我们还可以生成一些测试数据(一组key:value
)对。因此,测试Replication magic
的最简单方法是将数据导入Node 1
并设计一个非常简单的工具来监控'节点2'。
请注意,您预先定义了测试数据,因此您知道密钥并可以定期扫描Node 2
以获取相关值。收集延迟,错误等其他信息以简化进一步分析是个好主意。
解决类似的问题我使用方便的可视化来进一步简化分析。这是初始设计(实体大小也被跟踪,因为可能存在一些相关性):
这种方法简化了监控,而且,它允许调整系统,因为总是有相关的反馈。
我确实创建了一个模型实现来展示它的外观。基本上,测试逻辑可以描述如下:
Node 1
Node 2
获取值。在运行时,它可能如下所示(请不要忘记使用模型系统):
我定义了一些合理的限制因为复制过程实际上没有任何魔力,所以可能需要一些时间。
彻底设计的测试数据将揭示许多隐藏的秘密。