1.7. 站点间的客户端连接


客户端可以在 Active/Passive 或 Active/Active 配置中写入 Data Grid 集群。

Active/Passive

下图演示了主动/被动,其中 Data Grid 只处理一个站点的客户端请求:

在前面的镜像中:

  1. 客户端连接到 LON 上的 Data Grid 集群。
  2. 客户端将 "k1" 写入缓存。
  3. LON 的中继节点 "n1" 发送请求,以将"k1"复制到位于 NYC 的中继节点"nA"。

通过主动/被动,NYC 提供数据冗余。如果 LON 的 Data Grid 集群因任何原因而离线,客户端就可以开始向 NYC 发送请求。当您使 LON 恢复在线时,您可以将数据与 NYC 同步,然后将客户端切回到 LON

Active/Active

下图显示了在两个站点处理客户端请求的 Active/Active :

在前面的镜像中:

  1. 客户端 A 连接到 LON 上的 Data Grid 集群。
  2. 客户端 A 将 "k1" 写入缓存。
  3. 客户端 B 连接到位于 NYC 的 Data Grid 集群。
  4. 客户端 B 将"k2"写入缓存。
  5. LONNYC 发送请求的转发节点,以便"k1"复制到 NYC,"k2"复制到 LON

通过 Active/Active NYCLON 在处理客户端请求时将数据复制到远程缓存。如果 NYCLON 离线,客户端可以开始向在线站点发送请求。然后,您可以使离线站点重新上线,将状态推送到同步数据,并根据需要切换客户端。

备份策略和客户端连接

重要

建议使用 Active/Active 配置的异步备份策略(strategy=async)。

如果多个客户端尝试同时写入同一条目,并且备份策略是同步的(strategy=sync),则会出现死锁。但是,如果两个站点都访问不同的数据集,您可以使用同步备份策略,在这种情况下,不会出现并发写入的死锁风险。

1.7.1. 并发写入和冲突条目

如果客户端同时写入同一条目,但在不同的站点上,可能会发生冲突的条目,并带有 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  <--

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

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

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

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

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

提示

在站点名称前加上数字作为代表解析冲突条目的优先级顺序的简单方法;例如,1LON2NYC

备份策略

Data Grid 仅对异步备份策略(strategy=async)执行冲突解析。

您永远不会将同步备份策略与 Active/Active 配置一起使用。在这个配置并发写入会导致死锁和丢失数据。但是,如果两个站点都访问不同的数据集,您可以将同步备份策略与 Active/Active 配置一起使用,在这种情况下,不会出现并发写入的风险。

跨站点合并策略

除了配置 Data Grid 的跨站点合并策略外,数据源还提供 XSiteEntryMergePolicy SPI:

  • 始终删除冲突的条目。
  • 发生写/删除冲突时应用写入操作。
  • 当发生写/删除冲突时删除条目。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.