如何设置Redis客户端的超时时长？

「爱情、让人受尽委屈。」 2024-04-17 17:11 66阅读 0赞

客户端的超时时长分连接超时和读写超时，如果是基于hiredis的实现，则读写超时是合在一起的，同一参数控制。

在hiredis中，读写超时调用函数**redisSet****Timeout**设置，可以看到没有区分读和写：

<table style="width:426.1pt;"> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;width:426.1pt;"> int redisSetTimeout(redisContext *c, const struct timeval tv); </td> 
 </tr> 
 </tbody> 
</table>

而连接超时，则是在建立连接时指定：

<table style="width:426.1pt;"> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;width:426.1pt;"> redisContext *redisConnectWithTimeout(const char *ip, int port, const struct timeval tv); </td> 
 </tr> 
 </tbody> 
</table>

超时值设置偏小，容易导致访问redis失败。如果是写操作（set、lpush、hset、incrby等操作），则结果还有不确定性，即可能在redis端成功了，但客户端得到的是超时，象incrby和setnx等操作还不方便简单重试。

如果超时值设置过大，则在redis异常时不容易及时做切换，比如master卡住（可能因为在重写AOF而繁忙）时，调用者也将被卡住，不能及时解脱，一些情况下可能造成雪崩，这种情况下超时值越小越有利。

如何确定一个合理超时值了？原则是保证大多数超时都能成功，因此需要确定什么值可以满足大多数情况。这需考虑两个方面：

1.  网络延迟，通过ping掌握网络延迟

<table style="width:426.1pt;"> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;width:426.1pt;"> $ ping -c 3 192.168.1.22 PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data. 64 bytes from 192.168.1.22: icmp_seq=1 ttl=53 time=31.7&nbsp;ms 64 bytes from 192.168.1.22: icmp_seq=2 ttl=53 time=31.7 ms 64 bytes from 192.168.1.22: icmp_seq=3 ttl=53 time=31.7 ms &nbsp; --- 192.168.1.22 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 31.720/31.725/31.728/0.145 ms </td> 
 </tr> 
 </tbody> 
</table>

1.  查看redis慢日志

<table style="width:426.1pt;"> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;width:426.1pt;"> $ redis-cli slowlog get &nbsp;1) 1) (integer) 10526 &nbsp;&nbsp;&nbsp;&nbsp;2) (integer) 1566357322 &nbsp;&nbsp;&nbsp;&nbsp;3) (integer) 10926 &nbsp;&nbsp;&nbsp;&nbsp;4) 1) "ZCOUNT" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2) "test1" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) "-9223372036854775808" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4) "9223372036854775807" &nbsp;2) 1) (integer) 10525 &nbsp;&nbsp;&nbsp;&nbsp;2) (integer) 1566343237 &nbsp;&nbsp;&nbsp;&nbsp;3) (integer) 17572 &nbsp;&nbsp;&nbsp;&nbsp;4) 1) "HGET" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2) "test2" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) "tq" &nbsp;3) 1) (integer) 10524 &nbsp;&nbsp;&nbsp;&nbsp;2) (integer) 1566343212 &nbsp;&nbsp;&nbsp;&nbsp;3) (integer) 101400 &nbsp;&nbsp;&nbsp;&nbsp;4) 1) "HGET" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2) "test3" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) "tq" </td> 
 </tr> 
 </tbody> 
</table>

看“slowlog get”命令输出的第“3”条数值，比如上面的“**10926**”、“**17572**”和“**101400**”，分别表示对应命令执行的时长，单位为微秒。显然以上述为例，超时时长不能小于“102+32”毫秒，即读写超时至少得设置134毫秒。

显然实际中，超值时不可能很小，如果都是同步调用，调用相互耦合，一个redis节点异常即会影响全局，为此业务侧的架构应考虑到这一点。原则是一次业务操作只涉及单个redis节点，业务侧采用分机器、分进程或分线程方式解耦，这样即使某redis节点异常，也只会影响这部分数据，其它部分仍然可正常操作（这里建议redis的配置项cluster-require-**full-coverage**值为**no**）。