使用 Active-Active 数据库开发应用程序

概述为主动-主动数据库和独立 Redis 数据库开发应用程序有何不同。

Redis 企业软件 Redis 云

开发地理分布式、多主数据库应用程序可能很困难。 应用程序开发人员可能必须了解大量的 race 对各种站点、网络和集群的更新之间的条件 失败，这些失败可能会对事件重新排序并更改 跨地理分布式写入执行的更新。

主动-主动数据库（以前称为 CRDB）是跨多个 Redis Enterprise Software （RS） 集群的地理分布式数据库。 主动-主动数据库依赖于多主复制 （MMR） 和无冲突 复制数据类型 （CRDT） 支持简单的开发体验 适用于异地分布式应用程序。主动-主动数据库允许开发人员使用现有的 Redis 数据类型和命令，但了解开发人员的意图和 自动处理对同一键的冲突并发写入 跨多个地区。例如，开发人员可以简单地使用 Redis 中所有地理分布实例中的 INCR 或 INCRBY 方法 应用程序，主动-主动数据库处理 INCR 的附加性质，以反映 正确的最终值。以下示例显示一系列事件 随着时间的推移：T1 到 T9。此主动-主动数据库有两个成员主动-主动数据库：成员 CRDB1 和 成员 CRDB2。在每个成员 Active-Active 数据库中执行的本地作为 在成员 Active-Active 数据库名称下列出。“Sync” 甚至代表时刻 其中同步赶上以分发所有本地成员 Active-Active 数据库 对其他参与集群和其他成员主动-主动数据库的更新。

时间 成员 CRDB1 成员 CRDB2
T1 INCRBY 键1 7
T2 INCRBY 键1 3
T3 GET 键1
7		 GET 键1
3
T4 — 同步 — — 同步 —
T5 GET 键 1
10		 GET 键 1
10
T6 DECRBY 键 1 3
T7 INCRBY 键1 6
T8 — 同步 — — 同步 —
T9 GET 密钥 1
13		 GET 密钥 1
13

数据库提供了多种方法来解决其中一些问题：

  • 主动-被动异地分布式部署：使用主动-被动 distributions，则所有写入都将转到活动集群。Redis 企业版 提供了提供类似方法的 “Replica Of” 功能。 当工作负载高度平衡时，可以采用此方法 读取和少量写入。但是，WAN 性能和可用性 相当片状并且为了写入而被带走 从应用程序性能和可用性。
  • 两阶段提交 （2PC）：这种方法是围绕协议设计的 跨多个 Transaction Manager 提交事务。 两阶段提交提供一致的事务性写入 区域，但事务失败，除非所有参与的事务 经理在交易时是 “可用的”。数字 交换的消息数及其跨区域可用性 要求使两阶段提交甚至不适合中等 吞吐量和跨地理位置写入，这些写入通过 WAN 进行。
  • 同步更新与基于 Quorum 的写入：此方法同步 协调跨大多数副本的写入 跨多个区域的集群。然而，就像两相 commit、交换的消息数及其跨区域 可用性要求进行异地分布式仲裁写入 不适合中等吞吐量和跨地理位置写入 通过 WAN。
  • Last-Writer-Wins （LWW） 冲突解决：某些系统提供 针对所有类型的写入进行简单的冲突解决，其中 系统时钟用于确定冲突中的获胜者 写。LWW 是轻量级的，适用于更简单的数据。 但是，LWW 可能会对不一定的更新 冲突。例如，将新元素添加到跨两个的集合中 geographies 将只导致以下新 元素出现在最终结果中。
  • MVCC（多版本并发控制）：MVCC 系统维护 多个版本的数据，并且可能会为应用程序提供 解决冲突。尽管 MVCC 系统可以提供灵活的 解决写入冲突的方法，代价是 解决方案开发的复杂性。

即使主动-主动数据库中的类型和命令看起来与标准 Redis 相同 类型和命令，则 RS 中的基础类型得到了增强，以维护 更多元数据来创建无冲突的数据类型体验。这 部分介绍了您需要了解的有关使用 Active-Active 数据库进行开发的信息 Redis 企业软件。

Lua 脚本

主动-主动数据库支持 Lua 脚本，但与标准 Redis 不同，Lua 脚本始终 在 Effects 复制模式下执行。目前没有办法 在 script-replication 模式下执行它们。

驱逐

主动-主动数据库的默认策略是无驱逐模式。Redis Enterprise 版本 6.0.20 及更高版本支持主动-主动数据库的所有驱逐策略，除非启用了 Auto Tiering（以前称为 Redis on Flash）。 有关详细信息，请参阅主动-主动数据库的逐出。

呼气

特殊的多主语义支持 Expiration。

如果密钥的过期时间在不同 Active-Active 数据库的成员，通过 TTL 在键上设置的较长扩展时间为 保存。例如：

如果此命令是在集群 #1 上的 key1 上执行的

127.0.0.1:6379> EXPIRE key1 10

And if this command was performed on key1 on cluster #2

127.0.0.1:6379> EXPIRE key1 50

The EXPIRE command setting the key to 50 would win.

And if this command was performed on key1 on cluster #3:

127.0.0.1:6379> PERSIST key1

It would win out of the three clusters hosting the Active-Active database as it sets the TTL on key1 to an infinite time.

The replica responsible for the "winning" expire value is also responsible to expire the key and propagate a DEL effect when this happens. A "losing" replica is from this point on not responsible for expiring the key, unless another EXPIRE command resets the TTL. Furthermore, a replica that is NOT the "owner" of the expired value:

  • Silently ignores the key if a user attempts to access it in READ mode, e.g. treating it as if it was expired but not propagating a DEL.

  • Expires it (sending a DEL) before making any modifications if a user attempts to access it in WRITE mode.

    Note:
    Expiration values are in the range of [0, 2^49] for Active-Active databases and [0, 2^64] for non Active-Active databases.

Out-of-Memory (OOM)

If a member Active-Active database is in an out of memory situation, that member is marked "inconsistent" by RS, the member stops responding to user traffic, and the syncer initiates full reconciliation with other peers in the Active-Active database.

Active-Active Database Key Counts

Keys are counted differently for Active-Active databases:

  • DBSIZE (in shard-cli dbsize) reports key header instances that represent multiple potential values of a key before a replication conflict is resolved.
  • expired_keys (in bdb-cli info) can be more than the keys count in DBSIZE (in shard-cli dbsize) because expires are not always removed when a key becomes a tombstone. A tombstone is a key that is logically deleted but still takes memory until it is collected by the garbage collector.
  • The Expires average TTL (in bdb-cli info) is computed for local expires only.

INFO

The INFO command has an additional crdt section which provides advanced troubleshooting information (applicable to support etc.):

Section Field Description
CRDT Context crdt_config_version Currently active Active-Active database configuration version.
crdt_slots Hash slots assigned and reported by this shard.
crdt_replid Unique Replica/Shard IDs.
crdt_clock Clock value of local vector clock.
crdt_ovc Locally observed Active-Active database vector clock.
Peers A list of currently connected Peer Replication peers. This is similar to the slaves list reported by Redis.
Backlogs A list of Peer Replication backlogs currently maintained. Typically in a full mesh topology only a single backlog is used for all peers, as the requested Ids are identical.
CRDT Stats crdt_sync_full Number of inbound full synchronization processes performed.
crdt_sync_partial_ok Number of partial (backlog based) re-synchronization processes performed.
crdt_sync_partial-err Number of partial re-synchronization processes failed due to exhausted backlog.
crdt_merge_reqs Number of inbound merge requests processed.
crdt_effect_reqs Number of inbound effect requests processed.
crdt_ovc_filtered_effect_reqs Number of inbound effect requests filtered due to old vector clock.
crdt_gc_pending Number of elements pending garbage collection.
crdt_gc_attempted Number of attempts to garbage collect tombstones.
crdt_gc_collected Number of tombstones garbaged collected successfully.
crdt_gc_gvc_min The minimal globally observed vector clock, as computed locally from all received observed clocks.
crdt_stale_released_with_merge Indicates last stale flag transition was a result of a complete full sync.
CRDT Replicas A list of crdt_replica <uid> entries, each describes the known state of a remote instance with the following fields:
config_version Last configuration version reported.
shards Number of shards.
slots Total number of hash slots.
slot_coverage A flag indicating remote shards provide full coverage (i.e. all shards are alive).
max_ops_lag Number of local operations not yet observed by the least updated remote shard
min_ops_lag Number of local operations not yet observed by the most updated remote shard
RATE THIS PAGE
Back to top ↑