redis超时重试小结

2022-07-13 约 1469 字预计阅读 3 分钟

在互联网服务中，特别是在云环境下，网络及硬件环境复杂，所有应用程序都可能遇到暂时性故障。暂时性故障包括瞬时的网络抖动，服务暂时不可用，服务繁忙导致超时等，这些故障通常可以自我修复，在间隔一定时间后重试，则很大概率可以成功。

为什么会出现暂时性故障

云 Redis 集群的高可用

云 Redis 集群或者云环境中的很多产品，都是由大量机器组成的集群提供服务，机器可能发生各种各样的硬件故障，比如 CPU，内存，磁盘都可能发生故障。当故障发生时，Redis 服务会自动做 HA (High Available)，切换备用节点上来，客户端则可能遇到连接闪断，节点只读（主动 HA 流程需要对主禁止写入，从而让数据完整同步到备）等暂时性故障。

客户已知的慢查询瞬间打满Redis

如果 Redis 在定期执行一些已知的慢查询，比如（keys, hgetall, smembers）等复杂度为 O(N) 的操作，则可能导致其余 O(1) 复杂度的 API 出现暂时性失败。

复杂的网络环境

云上网络环境复杂，客户端和服务器之间的网络状况会不时改变，偶现网络抖动，数据包重传等问题。

重试的准则

适当的重试次数与间隔

必须优化重试次数与间隔。如果重试次数不足或者间隔太长，应用程序无法完成操作，并且可能失败。如果重试次数太多或者间隔太短，则可能会增大程序对系统资源的占用，且有可能造成服务端堆积太多请求无法恢复。确定适当的重试间隔是最困难的部分，常见的重试间隔如指数退让、增量间隔、固定间隔[1]等。

避免重试嵌套

大多数情况下，应该避免重试嵌套，嵌套容易造成反复重试且无法停止。

记录重试过程异常，但只有最终失败被报告

重试过程中，建议按照 WARN 级别打印重试的错误日志，但是只有最终重试失败时候才抛出 Exception，重试过程中如果能完成请求的正确访问，则不会打扰到用户。

超时之后不一定就可以重试

超时是一种未决现象，配置超时时间 2s，那么客户端通常的行为是当命令发送之后开始计时，如果在 2s 内没有成功收到回复，则客户端抛出 Timeout Exception。但此时服务端有没有执行过命令呢？是未决的，因为超时可能发生在任何阶段：

命令被客户端发出，但是还没有到达 Redis
命令到达 Redis，但是执行时候超时
命令执行结束，但是结果返回客户端时候超时

因此，对于有的命令，超时之后就不一定可以重试，是否可以重试的准则是命令执行是否幂等。

幂等操作才能重试

需要确定重试的操作是否为幂等的，例如：

set a b，就是幂等的，多次执行最终 a 的值只可能为 b 或者失败。
lpush list a，就不是幂等的，如果多次 lpush list a，则 list 中可能包含多个 a 元素。

Redis 常见客户端如何做重试

Redis 客户端开源生态繁荣，几乎各个编程语言都有对应的 Redis 客户端，Redis 官网（https://redis.io/clients）列出了很多 Redis 客户端，下面我们用go-redis客户端讨论如何做重试。

对于go-redis客户端来说，在Options中已经提供了超时的相关配置，我们只需要在调用NewClient方法时，传入我们创建好的Options结构即可，这样我们创建好的client就具备了超时重试的能力。

配置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 最大重试次数
MaxRetries int
// 重试间隔最小backoff值
MinRetryBackoff time.Duration
// 重试间隔最大backoff值
MaxRetryBackoff time.Duration

// 链接超时
DialTimeout time.Duration
// 读超时
ReadTimeout time.Duration
// 写超时
WriteTimeout time.Duration

默认的重试次数是3次，每次重试的时间间隔是根据backoff算法计算出来的，也就是上面配置的最大backoff和最小backoff两个配置，所有超时相关的重试机制，都是由上面三个配置决定的。

总结

本文总结了 Redis 导致超时的一些原因，为什么需要做重试，以及重试应当遵循的准则。并举例了go-redis客户端如何做重试。

目录