【问题标题】:EhCache dirty updates while replication复制时 EhCache 脏更新
【发布时间】:2016-03-13 20:15:19
【问题描述】:

我正在使用 EhCache 的 RMI 同步复制在 4 个托管服务器之间复制缓存。

我无法解决如何处理以下情况 - 假设我的节点 1 已收到缓存中存在的现有元素 (google) 的更新(假设为 google=$100),因此它会更新其元素服务器缓存并开始跨节点 2、3 和 4 进行复制。现在,在复制可以开始或到达节点 3 之前,节点 3 接收到同一元素的另一个更新 google=$103。因此,node3 更新其服务器缓存并开始跨其他节点 - node1、2 和 4 的复制。现在,由于 EhCache 使用读写锁,所以即使由节点 1 启动的复制(对于google=$100)到达节点 3,它将等待google=$103 更新在节点3 完成,然后google=$100 将在节点3 复制。

因此,基本上节点 3 以脏更新结束,因为最新值为 google=$103,但它将保持 google=$100

我的猜测是,这个问题只会出现在节点 3( 或任何在上次更新之前收到相同元素的另一个更新的节点可以复制到所有节点),因为对于节点 2和节点 4,首先 google=$100 将被复制,然后 google=$103 将被复制,因此它们将保存最新的值/更新。

我读到了 EhCache 的 BlockingCacheSelfPopulatingCache,但它也没有解决这个问题。

有人对此有任何想法或遇到过这个问题吗?

【问题讨论】:

    标签: java multithreading replication ehcache


    【解决方案1】:

    您面临的问题是分布式系统中的一致性问题。

    Ehcache 复制根本无法解决这个问题,而且比您描述的情况更多。

    如果您需要适当的一致性,则需要转向集群,这可以通过Terracotta 实现。

    注意:我在 Ehcache 和 Terracotta 工作。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-05-30
      • 1970-01-01
      • 1970-01-01
      • 2011-02-10
      • 2016-09-20
      • 2016-11-15
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多