Redis入门完整教程：客户端管理

Redis提供了客户端相关API对其状态进行监控和管理，本节将深入介绍
各个API的使用方法以及在开发运维中可能遇到的问题。

4.4.1　客户端API
1.client list
client list命令能列出与Redis服务端相连的所有客户端连接信息，例如下
面代码是在一个Redis实例上执行client list的结果：
127.0.0.1:6379> client list
id=254487 addr=10.2.xx.234:60240 fd=1311 name= age=8888581 idle=8888581 flags=N
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
id=300210 addr=10.2.xx.215:61972 fd=3342 name= age=8054103 idle=8054103 flags=N
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
id=5448879 addr=10.16.xx.105:51157 fd=233 name= age=411281 idle=331077 flags=N
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ttl
id=2232080 addr=10.16.xx.55:32886 fd=946 name= age=603382 idle=331060 flags=N
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
id=7125108 addr=10.10.xx.103:33403 fd=139 name= age=241 idle=1 flags=N db=0
sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=del
id=7125109 addr=10.10.xx.101:58658 fd=140 name= age=241 idle=1 flags=N db=0
sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=del
...
输出结果的每一行代表一个客户端的信息，可以看到每行包含了十几个
属性，它们是每个客户端的一些执行状态，理解这些属性对于Redis的开发
和运维人员非常有帮助。下面将选择几个重要的属性进行说明，其余通过表
格的形式进行展示。
（1）标识：id、addr、fd、name
这四个属性属于客户端的标识：
·id：客户端连接的唯一标识，这个id是随着Redis的连接自增的，重启
Redis后会重置为0。
·addr：客户端连接的ip和端口。
·fd：socket的文件描述符，与lsof命令结果中的fd是同一个，如果fd=-1
代表当前客户端不是外部客户端，而是Redis内部的伪装客户端。
·name：客户端的名字，后面的client setName和client getName两个命令
会对其进行说明。
（2）输入缓冲区：qbuf、qbuf-free
Redis为每个客户端分配了输入缓冲区，它的作用是将客户端发送的命
令临时保存，同时Redis从会输入缓冲区拉取命令并执行，输入缓冲区为客
户端发送命令到Redis执行命令提供了缓冲功能，如图4-5所示。
client list中qbuf和qbuf-free分别代表这个缓冲区的总容量和剩余容量，
Redis没有提供相应的配置来规定每个缓冲区的大小，输入缓冲区会根据输
入内容大小的不同动态调整，只是要求每个客户端缓冲区的大小不能超过
1G，超过后客户端将被关闭。下面是Redis源码中对于输入缓冲区的硬编
码：

 

/* Protocol and I/O related defines */
#define REDIS_MAX_QUERYBUF_LEN (1024*1024*1024) /* 1GB max query buffer. */
输入缓冲使用不当会产生两个问题：
·一旦某个客户端的输入缓冲区超过1G，客户端将会被关闭。
·输入缓冲区不受maxmemory控制，假设一个Redis实例设置了
maxmemory为4G，已经存储了2G数据，但是如果此时输入缓冲区使用了
3G，已经超过maxmemory限制，可能会产生数据丢失、键值淘汰、OOM等
情况（如图4-6所示）。

执行效果如下：

127.0.0.1:6390> info memory
# Memory
used_memory_human:5.00G
...
maxmemory_human:4.00G
....
上面已经看到，输入缓冲区使用不当造成的危害非常大，那么造成输入
缓冲区过大的原因有哪些？输入缓冲区过大主要是因为Redis的处理速度跟
不上输入缓冲区的输入速度，并且每次进入输入缓冲区的命令包含了大量
bigkey，从而造成了输入缓冲区过大的情况。还有一种情况就是Redis发生了
阻塞，短期内不能处理命令，造成客户端输入的命令积压在了输入缓冲区，
造成了输入缓冲区过大。
那么如何快速发现和监控呢？监控输入缓冲区异常的方法有两种：
·通过定期执行client list命令，收集qbuf和qbuf-free找到异常的连接记录
并分析，最终找到可能出问题的客户端。
·通过info命令的info clients模块，找到最大的输入缓冲区，例如下面命
令中的其中client_biggest_input_buf代表最大的输入缓冲区，例如可以设置超
过10M就进行报警：
127.0.0.1:6379> info clients
# Clients
connected_clients:1414
client_longest_output_list:0
client_biggest_input_buf:2097152
blocked_clients:0
这两种方法各有自己的优劣势，表4-3对两种方法进行了对比。

 

 

运维提示
输入缓冲区问题出现概率比较低，但是也要做好防范，在开发中要减少
bigkey、减少Redis阻塞、合理的监控报警。
（3）输出缓冲区：obl、oll、omem
Redis为每个客户端分配了输出缓冲区，它的作用是保存命令执行的结
果返回给客户端，为Redis和客户端交互返回结果提供缓冲，如图4-7所示。
与输入缓冲区不同的是，输出缓冲区的容量可以通过参数client-output-
buffer-limit来进行设置，并且输出缓冲区做得更加细致，按照客户端的不同
分为三种：普通客户端、发布订阅客户端、slave客户端，如图4-8所示。

 

 

对应的配置规则是：
client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
·<class>：客户端类型，分为三种。a）normal：普通客户端；b）
slave：slave客户端，用于复制；c）pubsub：发布订阅客户端。
·<hard limit>：如果客户端使用的输出缓冲区大于<hard limit>，客户端
会被立即关闭。
·<soft limit>和<soft seconds>：如果客户端使用的输出缓冲区超过了<soft
limit>并且持续了<soft limit>秒，客户端会被立即关闭。
Redis的默认配置是：
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
和输入缓冲区相同的是，输出缓冲区也不会受到maxmemory的限制，如
果使用不当同样会造成maxmemory用满产生的数据丢失、键值淘汰、OOM等
情况。
实际上输出缓冲区由两部分组成：固定缓冲区（16KB）和动态缓冲
区，其中固定缓冲区返回比较小的执行结果，而动态缓冲区返回比较大的结
果，例如大的字符串、hgetall、smembers命令的结果等，通过Redis源码中
redis.h的redisClient结构体（Redis3.2版本变为Client）可以看到两个缓冲区
的实现细节：
typedef struct redisClient {
//  动态缓冲区列表
list *reply;
//  动态缓冲区列表的长度 ( 对象个数 )
unsigned long reply_bytes;
//  固定缓冲区已经使用的字节数
int bufpos;
//  字节数组作为固定缓冲区
char buf[REDIS_REPLY_CHUNK_BYTES];
} redisClient;
固定缓冲区使用的是字节数组，动态缓冲区使用的是列表。当固定缓冲
区存满后会将Redis新的返回结果存放在动态缓冲区的队列中，队列中的每
个对象就是每个返回结果，如图4-9所示。

 

client list中的obl代表固定缓冲区的长度，oll代表动态缓冲区列表的长
度，omem代表使用的字节数。例如下面代表当前客户端的固定缓冲区的长
度为0，动态缓冲区有4869个对象，两个部分共使用了133081288字节=126M
内存：
id=7 addr=127.0.0.1:56358 fd=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 multi=-1
qbuf=0 qbuf-free=0 obl=0 oll=4869 omem=133081288 events=rw cmd=monitor
监控输出缓冲区的方法依然有两种：
·通过定期执行client list命令，收集obl、oll、omem找到异常的连接记录
并分析，最终找到可能出问题的客户端。
·通过info命令的info clients模块，找到输出缓冲区列表最大对象数，例
如：
127.0.0.1:6379> info clients
# Clients
connected_clients:502
client_longest_output_list:4869
client_biggest_input_buf:0
blocked_clients:0
其中，client_longest_output_list代表输出缓冲区列表最大对象数，这两
种统计方法的优劣势和输入缓冲区是一样的，这里就不再赘述了。相比于输
入缓冲区，输出缓冲区出现异常的概率相对会比较大，那么如何预防呢？方
法如下：
·进行上述监控，设置阀值，超过阀值及时处理。
·限制普通客户端输出缓冲区的，把错误扼杀在摇篮中，例如可以进行
如下设置：
client-output-buffer-limit normal 20mb 10mb 120
·适当增大slave的输出缓冲区的，如果master节点写入较大，slave客户
端的输出缓冲区可能会比较大，一旦slave客户端连接因为输出缓冲区溢出
被kill，会造成复制重连。
·限制容易让输出缓冲区增大的命令，例如，高并发下的monitor命令就
是一个危险的命令。
·及时监控内存，一旦发现内存抖动频繁，可能就是输出缓冲区过大。
（4）客户端的存活状态
client list中的age和idle分别代表当前客户端已经连接的时间和最近一次
的空闲时间：

id=2232080 addr=10.16.xx.55:32886 fd=946 name= age=603382 idle=331060 flags=N db=0
sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
例如上面这条记录代表当期客户端连接Redis的时间为603382秒，其中
空闲了331060秒：
id=254487 addr=10.2.xx.234:60240 fd=1311 name= age=8888581 idle=8888581 flags=N db=0
sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
例如上面这条记录代表当期客户端连接Redis的时间为8888581秒，其中
空闲了8888581秒，实际上这种就属于不太正常的情况，当age等于idle时，
说明连接一直处于空闲状态。
为了更加直观地描述age和idle，下面用一个例子进行说明：
String key = "hello";
// 1)  生成 jedis ，并执行 get 操作
Jedis jedis = new Jedis("127.0.0.1", 6379);
System.out.println(jedis.get(key));
// 2)  休息 10 秒
TimeUnit.SECONDS.sleep(10);
// 3)  执行新的操作 ping
System.out.println(jedis.ping());
// 4)  休息 5 秒
TimeUnit.SECONDS.sleep(5);
// 5)  关闭 jedis 连接
jedis.close();
下面对代码中的每一步进行分析，用client list命令来观察age和idle参数
的相应变化。

注意
为了与redis-cli的客户端区分，本次测试客户端IP地址：10.7.40.98。
1）在执行代码之前，client list只有一个客户端，也就是当前的redis-
cli，下面为了节省篇幅忽略掉这个客户端。
288
127.0.0.1:6379> client list
id=45 addr=127.0.0.1:55171 fd=6 name= age=2 idle=0 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
2）使用Jedis生成了一个新的连接，并执行get操作，可以看到IP地址为
10.7.40.98的客户端，最后执行的命令是get，age和idle分别是1秒和0秒：
127.0.0.1:6379> client list
id=46 addr=10.7.40.98:62908 fd=7 name= age=1 idle=0 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
3）休息10秒，此时Jedis客户端并没有关闭，所以age和idle一直在递
增：
127.0.0.1:6379> client list
id=46 addr=10.7.40.98:62908 fd=7 name= age=9 idle=9 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
4）执行新的操作ping，发现执行后age依然在增加，而idle从0计算，也
就是不再闲置：
127.0.0.1:6379> client list
id=46 addr=10.7.40.98:62908 fd=7 name= age=11 idle=0 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
5）休息5秒，观察age和idle增加：
127.0.0.1:6379> client list
id=46 addr=10.7.40.98:62908 fd=7 name= age=15 idle=5 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
6）关闭Jedis，Jedis连接已经消失：
redis-cli client list | grep "10.7.40.98 ”为空

（5）客户端的限制maxclients和timeout
Redis提供了maxclients参数来限制最大客户端连接数，一旦连接数超过
maxclients，新的连接将被拒绝。maxclients默认值是10000，可以通过info
clients来查询当前Redis的连接数：
127.0.0.1:6379> info clients
# Clients
connected_clients:1414
...
可以通过config set maxclients对最大客户端连接数进行动态设置：
127.0.0.1:6379> config get maxclients
1) "maxclients"
2) "10000"
127.0.0.1:6379> config set maxclients 50
OK
127.0.0.1:6379> config get maxclients
1) "maxclients"
2) "50"
一般来说maxclients=10000在大部分场景下已经绝对够用，但是某些情
况由于业务方使用不当（例如没有主动关闭连接）可能存在大量idle连接，
无论是从网络连接的成本还是超过maxclients的后果来说都不是什么好事，
因此Redis提供了timeout（单位为秒）参数来限制连接的最大空闲时间，一
旦客户端连接的idle时间超过了timeout，连接将会被关闭，例如设置timeout
为30秒：
#Redis 默认的 timeout 是 0 ，也就是不会检测客户端的空闲
127.0.0.1:6379> config set timeout 30
OK
下面继续使用Jedis进行模拟，整个代码和上面是一样的，只不过第2）
步骤休息了31秒：

String key = "hello";
// 1)  生成 jedis ，并执行 get 操作
Jedis jedis = new Jedis("127.0.0.1", 6379);
System.out.println(jedis.get(key));
// 2)  休息 31 秒
TimeUnit.SECONDS.sleep(31);
// 3)  执行 get 操作
System.out.println(jedis.get(key));
// 4)  休息 5 秒
TimeUnit.SECONDS.sleep(5);
// 5)  关闭 jedis 连接
jedis.close();

执行上述代码可以发现在执行完第2）步之后，client list中已经没有了
Jedis的连接，也就是说timeout已经生效，将超过30秒空闲的连接关闭掉：
127.0.0.1:6379> client list
id=16 addr=10.7.40.98:63892 fd=6 name= age=19 idle=19 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
#  超过 timeout 后， Jedis 连接被关闭
redis-cli client list | grep  “ 10.7.40.98 ”为空
同时可以看到，在Jedis代码中的第3）步抛出了异常，因为此时客户端
已经被关闭，所以抛出的异常是JedisConnectionException，并且提示
Unexpected end of stream：
stream ：
world
Exception in thread "main" redis.clients.jedis.exceptions.JedisConnectionException:
Unexpected end of stream.
如果将Redis的loglevel设置成debug级别，可以看到如下日志，也就是客
户端被Redis关闭的日志：
12885:M 26 Aug 08:46:40.085 - Closing idle client
Redis源码中redis.c文件中clientsCronHandleTimeout函数就是针对timeout
参数进行检验的，只不过在源码中timeout被赋值给了server.maxidletime：

int clientsCronHandleTimeout(redisClient *c) {
//  当前时间
time_t now = server.unixtime;
// server.maxidletime 就是参数 timeout
if (server.maxidletime &&
//  很多客户端验证，这里就不占用篇幅，最重要的验证是下面空闲时间超过了 maxidletime 就会
//  被关闭掉客户端
(now - c->lastinteraction > server.maxidletime))
{
redisLog(REDIS_VERBOSE,"Closing idle client");
//  关闭客户端
freeClient(c);
}
}

Redis的默认配置给出的timeout=0，在这种情况下客户端基本不会出现
上面的异常，这是基于对客户端开发的一种保护。例如很多开发人员在使用
JedisPool时不会对连接池对象做空闲检测和验证，如果设置了timeout>0，可
能就会出现上面的异常，对应用业务造成一定影响，但是如果Redis的客户
端使用不当或者客户端本身的一些问题，造成没有及时释放客户端连接，可
能会造成大量的idle连接占据着很多连接资源，一旦超过maxclients；后果也
是不堪设想。所在在实际开发和运维中，需要将timeout设置成大于0，例如
可以设置为300秒，同时在客户端使用上添加空闲检测和验证等等措施，例
如JedisPool使用common-pool提供的三个属性：minEvictableIdleTimeMillis、
testWhileIdle、timeBetweenEvictionRunsMillis，4.2节已经进行了说明，这里
就不再赘述。
（6）客户端类型
client list中的flag是用于标识当前客户端的类型，例如flag=S代表当前客
户端是slave客户端、flag=N代表当前是普通客户端，flag=O代表当前客户端
正在执行monitor命令，表4-4列出了11种客户端类型。

 （7）其他
上面已经将client list中重要的属性进行了说明，表4-5列出之前介绍过
以及一些比较简单或者不太重要的属性。

2.client setName和client getName
client setName xx
client getName
client setName用于给客户端设置名字，这样比较容易标识出客户端的来
源，例如将当前客户端命名为test_client，可以执行如下操作：
127.0.0.1:6379> client setName test_client
OK
此时再执行client list命令，就可以看到当前客户端的name属性为
test_client：
127.0.0.1:6379> client list
id=55 addr=127.0.0.1:55604 fd=7 name=test_client age=23 idle=0 flags=N db=0 sub=0
psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
如果想直接查看当前客户端的name，可以使用client getName命令，例如
下面的操作：
127.0.0.1:6379> client getName
"test_client"
client getName和setName命令可以做为标识客户端来源的一种方式，但
是通常来讲，在Redis只有一个应用方使用的情况下，IP和端口作为标识会
更加清晰。当多个应用方共同使用一个Redis，那么此时client setName可以
作为标识客户端的一个依据。
3.client kill
client kill ip:port
此命令用于杀掉指定IP地址和端口的客户端，例如当前客户端列表为：
127.0.0.1:6379> client list
id=49 addr=127.0.0.1:55593 fd=6 name= age=9 idle=0 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
id=50 addr=127.0.0.1:52343 fd=7 name= age=4 idle=4 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
如果想杀掉127.0.0.1：52343的客户端，可以执行：
127.0.0.1:6379> client kill 127.0.0.1:52343
OK
执行命令后，client list结果只剩下了127.0.0.1：55593这个客户端：
127.0.0.1:6379> client list
id=49 addr=127.0.0.1:55593 fd=6 name= age=9 idle=0 flags=N db=0 sub=0 psub=0
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
由于一些原因（例如设置timeout=0时产生的长时间idle的客户端），需
要手动杀掉客户端连接时，可以使用client kill命令。
4.client pause
client pause timeout( 毫秒 )
如图4-10所示，client pause命令用于阻塞客户端timeout毫秒数，在此期
间客户端连接将被阻塞。 

例如在一个客户端执行：
127.0.0.1:6379> client pause 10000
OK
在另一个客户端执行ping命令，发现整个ping命令执行了9.72秒（手动
执行redis-cli，只为了演示，不代表真实执行时间）：
127.0.0.1:6379> ping
PONG
(9.72s)
该命令可以在如下场景起到作用：

·client pause只对普通和发布订阅客户端有效，对于主从复制（从节点
内部伪装了一个客户端）是无效的，也就是此期间主从复制是正常进行的，
所以此命令可以用来让主从复制保持一致。
·client pause可以用一种可控的方式将客户端连接从一个Redis节点切换
到另一个Redis节点。
需要注意的是在生产环境中，暂停客户端成本非常高。
5.monitor
monitor命令用于监控Redis正在执行的命令，如图4-11所示，我们打开
了两个redis-cli，一个执行set get ping命令，另一个执行monitor命令。可以看
到monitor命令能够监听其他客户端正在执行的命令，并记录了详细的时间
戳。 

monitor的作用很明显，如果开发和运维人员想监听Redis正在执行的命
令，就可以用monitor命令，但事实并非如此美好，每个客户端都有自己的
输出缓冲区，既然monitor能监听到所有的命令，一旦Redis的并发量过大，
monitor客户端的输出缓冲会暴涨，可能瞬间会占用大量内存，图4-12展示了
monitor命令造成大量内存使用。 

4.4.2　客户端相关配置
4.4.1节已经介绍了部分关于客户端的配置，本节将对剩余配置进行介
绍：
·timeout：检测客户端空闲连接的超时时间，一旦idle时间达到了
timeout，客户端将会被关闭，如果设置为0就不进行检测。
·maxclients：客户端最大连接数，4.4.1节中的客户端存活状态部分已经
进行分析，这里不再赘述，但是这个参数会受到操作系统设置的限制，第12
章Linux相关配置小节还会对这个参数进行介绍。
·tcp-keepalive：检测TCP连接活性的周期，默认值为0，也就是不进行
检测，如果需要设置，建议为60，那么Redis会每隔60秒对它创建的TCP连
接进行活性检测，防止大量死连接占用系统资源。
·tcp-backlog：TCP三次握手后，会将接受的连接放入队列中，tcp-
backlog就是队列的大小，它在Redis中的默认值是511。通常来讲这个参数不
需要调整，但是这个参数会受到操作系统的影响，例如在Linux操作系统
中，如果/proc/sys/net/core/somaxconn小于tcp-backlog，那么在Redis启动时会
看到如下日志，并建议将/proc/sys/net/core/somaxconn设置更大。
# WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/
sys/net/core/somaxconn is set to the lower value of 128.
修改方法也非常简单，只需要执行如下命令：
echo 511 > /proc/sys/net/core/somaxconn

4.4.3　客户端统计片段
例如下面就是一次info clients的执行结果：
127.0.0.1:6379> info clients
# Clients
connected_clients:1414
client_longest_output_list:0
client_biggest_input_buf:2097152
blocked_clients:0
说明如下：
1）connected_clients：代表当前Redis节点的客户端连接数，需要重点监
控，一旦超过maxclients，新的客户端连接将被拒绝。
2）client_longest_output_list：当前所有输出缓冲区中队列对象个数的最
大值。
3）client_biggest_input_buf：当前所有输入缓冲区中占用的最大容量。
4）blocked_clients：正在执行阻塞命令（例如blpop、brpop、
brpoplpush）的客户端个数。
除此之外info stats中还包含了两个客户端相关的统计指标，如下：
127.0.0.1:6379> info stats
# Stats
total_connections_received:80
...
rejected_connections:0
参数说明：
·total_connections_received：Redis自启动以来处理的客户端连接数总
数。
·rejected_connections：Redis自启动以来拒绝的客户端连接数，需要重点
监控。