全球多活使用限制

使用限制

• 子实例需满足以下条件：

  • 部署模式为经典（原本地盘）。

  • 存储介质为内存型。

  • 架构为标准架构或集群架构。

  说明

  请确保各子实例规格一致，如需进行变配，建议对所有子实例均进行相同变配。若各子实例的规格不一致，可能会出现性能或容量问题。

• 一个分布式实例中最多可包含三个子实例，且各子实例不能位于同一可用区。第一个子实例支持从已创建的实例进行转换，第二、第三个子实例需新购。

• 一个分布式实例中的子实例必须都在中国内地或都在其他地域，若您需要在中国内地地域与其他地域之间进行数据同步，请使用DTS数据同步功能，更多信息请参见申请跨境数据同步权限。

• 成为分布式实例的子实例后，存在如下限制：

  • 不支持变更实例所属的可用区。

  • 不支持变更实例架构，例如从集群架构变更为标准架构等。

  • 集群实例变配时，单次仅支持变配分片数或分片规格，更多信息请参见分布式集群实例变配方案。

同步命令限制

• FLUSHDB或FLUSHALL命令不会被同步。如需清空数据，需对所有子实例执行FLUSHDB或FLUSHALL命令，否则会造成数据不一致。

• Pub和Sub命令不会被同步，如需实现跨域通知的消息复制，建议通过Stream数据结构来实现。

• 同步RESTORE命令时，如果目标子实例具备相同的Key，则不会被执行。

同步粒度限制

数据一致性限制

• 单写场景下（例如用作灾备场景），数据的一致性级别为最终数据一致。

• 多写场景下（例如用作多活场景），业务上应避免多个子实例在同一时刻或相近的时间修改同一个Key，否则可能造成数据不一致（即无法保障Key的最终一致性）或者数据堆积（在Streaming场景下严格递增产生的冲突），如下表所示。

  说明

  全球多活暂不支持CRDT（Conflict-Free Replicated Data Type）约束，您需要从业务层面自行保障。

  不一致情况	图示	说明
  value互换		子实例A在1.1时刻收到SET命令（key->value_A），并于1.2时刻将数据写入数据库。 子实例B在2.1时刻收到SET命令（key->value_B），并于2.2时刻将数据写入数据库。 在3.1时刻子实例A向子实例B同步数据（key->value_A），同时子实例B向子实例A同步数据（key->value_B）。 同步完成，两个子实例中key对应的value发生了互换。
  乱序或丢失		子实例A在1.1时刻收到命令（rpush key->value_A），并于1.2时刻将数据写入至数据库。 子实例B在2.1时刻收到命令（rpush key->value_B），并于2.2时刻将数据写入至数据库。 在3.1时刻子实例A向子实例B同步数据（rpush key->value_A），同时子实例B向子实例A同步数据（rpush key->value_B）。 当操作类型依赖value原始值时，在交换的情况下可能会出现乱序甚至丢失的情况。 说明 可能造成类似问题的还有、lpush，lpop、append、sort（store）、del、hdel、incr、xadd系列等操作。
  类型不一致		子实例A在1.1时刻收到命令（key->T(hash)），并于1.2时刻将数据写入至数据库。 子实例B在2.1时刻收到命令（key->T(string)），并于2.2时刻将数据写入至数据库。 在3时刻子实例间执行数据同步将形成冲突。
  写入条件不满足		子实例A在1.1时刻收到命令（setnx key->value_A），并于1.2时刻将数据写入至数据库。 子实例B在2.1时刻收到命令（setnx key->value_B），并于2.2时刻将数据写入至数据库。 在3时刻子实例间执行数据同步将形成冲突。 说明 可能造成类似问题的还有set(nx | xx)、hsetnx操作。