2.4. 异步复制
所有集群缓存模式都可以配置为在 < replicated-cache/>、<
使用与 distributed-cache> 或 <
; invalidation-cache/&
gt; 元素中mode="ASYNC"
属性的异步通信。
通过异步通信,原始器节点不会收到来自其他节点有关操作状态的任何确认,因此无法检查它是否在其他节点上成功。
我们不推荐一般推荐异步通信,因为它们可能会导致数据中的不一致,并且结果很难考虑。然而,有时速度比一致性更重要,而选项则适用于这些情况。
Asynchronous API
Asynchronous API 允许您使用同步通信,但不阻止用户线程。
存在一个注意事项:异步操作不会保留程序顺序。如果线程调用 cache.putAsync (k, v1); cache.putAsync (k, v2)
,则 k
的最终值可以是 v1
或 v2
。与使用异步通信相比,最终的值不能在一个节点上是 v1
,而 v2
则位于另一个节点上。
2.4.1. 使用异步复制返回值
由于 缓存
接口扩展了 java.util.Map
,因此默认情况下写入方法(如 put (key, value)
和 remove (key)
会返回之前的值。
在某些情况下,返回的值可能不正确:
-
将
AdvancedCache.withFlags ()
与Flag.IGNORE_RETURN_VALUE
,Flag.SKIP_REMOTE_LOOKUP
, 或Flag.SKIP_CACHE_LOAD
. -
当使用
不可靠的-return-values="true" 配置缓存时
。 - 使用异步通信时。
- 当同一键有多个并发写入时,缓存拓扑会改变。拓扑更改将使 Data Grid 重试写操作,而重试操作的返回值并不可靠。
事务缓存在 3 和 4 情况下返回正确的值。但是,事务性缓存在分布式模式下也有一个 gotcha:,read-committed 的隔离级别被实施为可重复读取。这意味着,"double-checked locking"示例无法正常工作:
Cache cache = ... TransactionManager tm = ... tm.begin(); try { Integer v1 = cache.get(k); // Increment the value Integer v2 = cache.put(k, v1 + 1); if (Objects.equals(v1, v2) { // success } else { // retry } } finally { tm.commit(); }
实现这一点的正确方法是使用 cache.getAdvancedCache ().withFlags (Flag.FORCE_WRITE_LOCK).get (k)
。
在具有最佳锁定的缓存中,写入也可以返回过时的之前值。编写偏移检查可以避免过时的之前值。