客户端地理故障转移
提示
来自deepseek解释
原文链接:https://redis.io/docs/latest/develop/clients/failover/
某些 Redis 客户端库支持客户端地理故障转移,以提高 Redis 数据库连接的可用性。使用本页面获取概念的一般概述,然后参阅您的客户端库文档,了解如何配置故障转移和故障恢复。
支持的客户端库
下表列出了支持客户端地理故障转移的客户端,以及它们的发布状态和可用功能。
| 客户端 | 基本故障转移 | Pub/sub 故障转移 | OSS Cluster 故障转移 | 故障恢复 |
|---|---|---|---|---|
| Jedis | 是 | 否 | 否 | 是 |
| redis-py | 是(预览) | 是 | 是 | 是 |
| Lettuce | 是(预览) | 是 | 否 | 是 |
概念
您可能拥有多个 Active-Active 数据库 或独立的 Redis 服务器,它们都适合为您的应用程序提供服务。通常情况下,对于应用程序的特定实例,您会优先使用某些数据库端点而非其他端点(可能是地理位置上最接近应用服务器的端点,以减少网络延迟)。但是,如果由于故障导致最佳端点不可用,通常切换到另一个次优端点也比让应用程序完全失败要好。
故障转移 是一种主动检查连接故障或不可接受的低速连接,并在发生时自动切换到最佳可用端点的技术。这要求您指定一个按优先级排序的端点列表。下图展示了此过程:
故障恢复 作为补充技术,涉及定期检查所有故障端点的健康状况。如果任何端点恢复,故障恢复机制会自动将连接切换到优先级最高的端点。这一过程可能重复进行,直到最优端点再次可用。
检测连接问题
Redis 客户端使用熔断器设计模式来检测连接问题。
熔断器是一个软件组件,它跟踪最近的 Redis 连接尝试和命令序列,记录哪些成功、哪些失败。(请注意,许多命令失败是由超时等瞬时错误引起的,因此在记录失败之前,通常首先应该重试命令几次。)
尝试的命令调用的状态保存在一个“滑动窗口”中,这本质上是一个缓冲区,每当添加新条目时,最旧的条目就会被丢弃。该缓冲区可以配置为基于时间窗口的固定失败次数和/或失败比率(以百分比表示)。
当窗口中的失败次数超过配置的阈值时,熔断器将该服务器声明为不健康,并触发故障转移。
选择故障转移目标
由于您可能有多个可用的 Redis 服务器用于故障转移,客户端允许您配置一个按优先级或“权重”排序的端点列表。当触发故障转移时,客户端会选择权重最高且仍然健康的端点,并将其用作临时连接。
健康检查
鉴于原始端点在地理位置或其他方面相对于故障转移目标具有优势,您通常希望在其恢复后尽快故障恢复。在此期间,另一台服务器可能恢复,其性能仍优于当前故障转移目标,因此即使该服务器不是最优的,故障恢复到它也可能值得。
客户端定期对每个服务器执行“健康检查”,以查看其是否已恢复。所有客户端都实现了以下几种健康检查策略:
- Ping:这是默认策略,仅发送
PING命令并确保其返回预期响应。 - 滞后感知(仅限 Redis Software):此策略使用 REST API 来检查特定数据库与 Active-Active 设置中其他数据库之间的同步滞后。如果滞后在指定的容差范围内,则认为该服务器是健康的。
- 自定义:您可以实现自己的健康检查策略,以利用特定于您的应用程序的信息或执行特定操作。
有关如何配置健康检查的更多信息,请参阅您的客户端库文档。
您还可以将客户端配置为在空闲期间对当前目标服务器执行健康检查,即使未发生故障转移。这有助于在您的应用程序未主动使用服务器时检测问题。