1.6. 跨站点的客户端连接

如果客户端同时写入同一条目，但在不同的站点上，可能会发生冲突的条目，并带有 Active/Active 站点配置。

例如，当客户端 B 写入 NYC 中的 "k1" 时，客户端 A 写入 LON 中的 "k1"。在这种情况下，"k1" 在 LON 中与 NYC 中的值不同。在进行复制后，不能保证哪个站点存在"k1"的值。

为确保数据一致性，Data Grid 使用向量时钟算法在备份操作过程中检测冲突的条目，如下例所示：

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

向量时钟是与每个写入条目递增的时间戳元数据。在前面的示例中，0 代表 "k1" 上向量时钟的初始值。

客户端将 "k1=2" 置于 LON 中，向量时钟为 1,0，数据网格复制到 NYC。然后，客户端将 "k1=3" 置于 NYC 中，并将向量时钟更新为 1,1，后者的数据网格复制到 LON。

但是，如果客户端同时将"k1=5"置于 LON 中，则客户端会将 "k1=8" 置于 NYC 中，则数据网格检测到冲突条目，因为 "k1" 的向量值在 LON 和 NYC 之间不严格更大或更少。

当找到冲突的条目时，Data Grid 使用 Java compareTo (String anotherString) 方法来比较站点名称。要确定哪个键具有优先级，Data Grid 选择不适合其他的站点名称。名为 AAA 的站点的键优先于名为 AAB 的站点的密钥，以此类推。

在同一示例后，为了解决"k1"的冲突，Data Grid 使用源自 LON 的 "k1" 的值。这会在 Data Grid 解析冲突并复制值后，在 LON 和 NYC 中都生成 "k1=5"。

冲突解析算法

除了 XSiteEntryMergePolicy SPI 外，Data Grid 提供了不同的算法来解决冲突，可让您实现自定义冲突解析策略。

除了使用字典比较的默认冲突解析策略外，您还可以使用 Data Grid 冲突解析算法来：

在 org.infinispan.xsite.spi.XSiteMergePolicy enum 中查找所有可用的算法及其描述。