使用主动-主动数据库进行应用程序故障转移
如何对应用程序进行故障转移以连接到远程副本。
| Redis 企业软件 | Redis 云 |
|---|
主动-主动 Redis 部署没有用于应用程序连接的内置故障转移或故障恢复机制。 使用主动-主动数据库部署的应用程序连接到地理位置附近的数据库副本。 如果该副本不可用，应用程序可以故障转移到远程副本，并在必要时再次故障回复。 在本文中，我们将解释此过程的工作原理。
主动-主动连接故障转移可以提高数据可用性，但可能会对数据一致性产生负面影响。 主动-主动复制与 Redis 复制一样，是异步的。 故障转移到另一个副本的应用程序可能会错过写入作。 如果失败的副本将写入作保存在持久存储中，则 然后，当失败的副本恢复时，将处理写入作。
检测故障
您的应用程序可以检测到两种类型的故障：
- 本地故障 - 本地副本已关闭或不可用
- 复制失败 - 本地副本可用，但无法复制到远程副本或从远程副本复制
本地故障
当应用程序由于任何原因无法连接到数据库终端节点时，会检测到本地故障。本地故障的原因可能包括：多个节点故障、配置错误、连接被拒绝、连接超时、意外的协议级别错误。
复制失败
复制失败更难在不导致误报的情况下进行可靠检测。复制失败可能包括：网络拆分、复制配置问题、远程副本失败。
运行状况检查复制的最可靠方法是使用 Redis 发布/订阅 （pub/sub） 机制。
当您使用 pub/sub 数据类型检测故障时，应用程序将：
- 连接到所有副本并为每个副本订阅专用通道。
- 连接到所有副本并定期发布唯一可识别的消息。
- 监控收到的消息，并确保它能够在预定的时间窗口内接收自己的消息。
您还可以使用已知的数据集更改来监控复制流的可靠性。 但 Pub/Sub 是首选方法，因为：
- 它不涉及数据集更改。
- 它不对数据集做出任何假设。
- 发布/订阅消息作为复制效果传递，是实时复制链接的更可靠指示器。在某些情况下，即使复制链接失败，数据集密钥也可能显示为已修改。发生这种情况是因为键可能通过完整状态复制（重新同步）或通过效果的在线复制来接收更新。
分片对故障检测的影响
如果您的分片配置是对称的，请确保每个分片至少使用一个键（PUB/SUB 通道或实际数据集键）。分片是单独复制的，容易出现故障。对称分片配置对所有副本具有相同数量的分片和哈希槽。 我们不建议使用非对称分片配置，该配置要求每个与一对分片相交的哈希槽至少有一个键。
要确保每个分片至少有一个键，应用程序应该：
- 使用 Cluster API 检索数据库分片配置。
- 计算多个键名称，以便每个分片有一个键。
- 将这些键名称用作发布/订阅机制的频道名称。
故障转移
当应用程序需要故障转移到另一个副本时，它只需重新建立与远程副本上的终端节点的连接即可。由于主动/主动复制和 Redis 复制是异步的，因此远程终端节点可能没有所有本地执行和确认的写入。
最好不读取自己的最近写入。这些写入可以是：
- 如果本地副本发生双重故障或持久文件丢失等事件，则永久丢失。
- 暂时不可用，但如果本地副本的故障是暂时的，则稍后将可用。
故障回复决策
您的应用程序可以使用上述相同的检查在故障转移后继续监控失败副本的状态。
要在故障回复过程中监控副本的状态，必须确保副本可用，与远程副本重新同步，并且不处于过时模式。PUB/SUB 机制是监视此情况的有效方法。
基于数据集的机制可能不太可靠，原因如下：
- 为了确定本地副本是否过时，仅从中读取键是不够的。您还必须尝试写入它。
- 如上所述，某些键的远程写入会在复制链接备份之前以及副本仍处于过时模式时出现在本地副本中。
- 从未写入的副本永远不会过时，因此在启动时，它会立即准备就绪，但会提供较长时间的过时数据。
副本配置更改
所有故障转移和故障回复作都应严格在应用程序端完成，并且不应涉及对主动-主动配置的更改。 重新配置 Active-Active 部署并删除副本的唯一有效情况是内存消耗变得过高，因为无法执行垃圾回收。 删除副本后，它只能重新加入为新副本，并且会丢失任何未聚合的写入。