客户端的超时时长分连接超时和读写超时，如果是基于hiredis的实现，则读写超时是合在一起的，同一参数控制。
在hiredis中，读写超时调用函数redisSetTimeout设置，可以看到没有区分读和写：
int redisSetTimeout(redisContext *c, const struct timeval tv); |
而连接超时，则是在建立连接时指定：
redisContext *redisConnectWithTimeout(const char *ip, int port, const struct timeval tv); |
超时值设置偏小，容易导致访问redis失败。如果是写操作（set、lpush、hset、incrby等操作），则结果还有不确定性，即可能在redis端成功了，但客户端得到的是超时，象incrby和setnx等操作还不方便简单重试。
如果超时值设置过大，则在redis异常时不容易及时做切换，比如master卡住（可能因为在重写AOF而繁忙）时，调用者也将被卡住，不能及时解脱，一些情况下可能造成雪崩，这种情况下超时值越小越有利。
如何确定一个合理超时值了？原则是保证大多数超时都能成功，因此需要确定什么值可以满足大多数情况。这需考虑两个方面：
1) 网络延迟，通过ping掌握网络延迟
$ 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 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 --- 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 |
2) 查看redis慢日志
$ redis-cli slowlog get 1) 1) (integer) 10526 2) (integer) 1566357322 3) (integer) 10926 4) 1) "ZCOUNT" 2) "test1" 3) "-9223372036854775808" 4) "9223372036854775807" 2) 1) (integer) 10525 2) (integer) 1566343237 3) (integer) 17572 4) 1) "HGET" 2) "test2" 3) "tq" 3) 1) (integer) 10524 2) (integer) 1566343212 3) (integer) 101400 4) 1) "HGET" 2) "test3" 3) "tq" |
看“slowlog get”命令输出的第“3”条数值，比如上面的“10926”、“17572”和“101400”，分别表示对应命令执行的时长，单位为微秒。显然以上述为例，超时时长不能小于“102+32”毫秒，即读写超时至少得设置134毫秒。
显然实际中，超值时不可能很小，如果都是同步调用，调用相互耦合，一个redis节点异常即会影响全局，为此业务侧的架构应考虑到这一点。原则是一次业务操作只涉及单个redis节点，业务侧采用分机器、分进程或分线程方式解耦，这样即使某redis节点异常，也只会影响这部分数据，其它部分仍然可正常操作（这里建议redis的配置项cluster-require-full-coverage值为no）。