redis学习笔记4-客户端管理
1.客户端管理
1.1 client list指令
id：客户端连接标识
addr：客户端IP和端口
fd：如果为-1表示是redis内部的伪装客户端
name：客户端名字
1.1.1输入缓冲区：qbuf、qbuf-free
qbuf：输入缓冲区总容量
qbuf-free：输入缓冲区剩余容量
注意：
某个客户端的输入缓冲区超过1G，客户端将会被关闭
输入缓冲区不受redis的maxmemory参数的控制，如果所有客户端输入缓冲区之和加上redis缓存数据大于maxmemory，则可能会产生数据丢失、键值淘汰、OOM等情况
可能出问题的原因：
redis的处理速度跟不上输入缓冲区的增长速度，即并发太大
客户端提交的数据包含大量bigkey，造成输入缓冲区过大
redis发生了阻塞，短期内不能处理命令，需要进行慢查询分析
解决方案：
定期执行client list指令，收集和分析输入缓冲区数据，找到可能出问题的客户端
通过修改连接数和每个客户端连接的输入输出缓冲区大小
总结：在开发中要减少bigkey、减少redis阻塞指令、合理的监控报警
1.1.2 输出缓冲区：obl、oll、omem
obl：固定缓冲区长度
oll：动态缓冲区列表的长度
omem：输出缓冲区使用的字节数
注意：
输出缓冲区可以通过client-output-buffer-limit按照客户端的不同进行配置，客户端分为普通客户端、发布订阅客户端、slave客户端。
client-output-buffer-limit <class> <hard limit> <soft-limit> <soft-seconds>
class：客户端类型
hard limit：如果输出缓冲区大于这个值，客户端将被关闭
oft-limit soft-seconds：客户端输出缓冲区超过oft-limit并且持续了soft-seconds秒后客户端将被关闭
如下为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
预防方案：
进行监控，设置阈值，超过阈值及时处理
限制普通客户端的输出缓冲区
根据并发情况，适当增大slave的输出缓冲区
限制容易让输出缓冲区增大的命令，如在高并发下的monitor命令
及时监控内存，如果出现内存抖动频繁，可能是输出缓冲区过大
1.1.3 客户端的存活状态：age idle
age：客户端连接上redis到现在一共经历了多少秒
idle：客户端最后一次提交指令到现在空闲了多少秒
注意：
redis默认的最大空闲时间参数为timeout=0，表示连接上来的客户端不管空闲多久都不会被断开，如果设置大于0，则在时间到了后会断开客户端的连接。
解决方案：
redis设置timeout大于0，同时在客户端如jedis中添加空闲检测和连接是否断开的验证措施
1.1.4 客户端类型：flag
1.2 client kill 指令
如client kill 127.0.0.1:52343，手动杀掉某客户端。
1.3 monitor指令
用于监控redis正在执行的指令，如果redis并发量过大，则可能导致monitor客户端的输出缓冲区暴涨，进而影响redis服务。
1.4 其他配置
timeout配置：检测客户端空闲连接超时时间
maxclients配置：客户端最大连接数
tcp-keepalive配置：检测TCP连接活性的周期，建议设置为60，则redis每60秒就会对它创建的TCP连接进行活性检测，防止大量死连接占用系统资源。
1.5 其他指令
1.5.1 info clients
connected_clients：代表当前Redis节点的客户端连接数，需要重点监控，一旦超过maxclients，新的客户端连接将被拒绝。
client_longest_output_list：当前所有输出缓冲区中队列对象个数的最大值。
client_biggest_input_buf：当前所有输入缓冲区中占用的最大容量。
blocked_clients：正在执行阻塞命令（例如blpop、brpop、brpoplpush）的客户端个数。
1.5.2 info stats
·total_connections_received：Redis自启动以来处理的客户端连接数总数。
·rejected_connections：Redis自启动以来拒绝的客户端连接数，需要重点监控。
2. 客户端常见异常
2.1 无法从连接池获取连接
Could not get a resoure from the pool
客户端连接池设置过小，出现供不应求
客户端没有正确使用连接池，比如没有进行释放
客户端存在慢查询，这些慢查询持有的jedis对象归还速度慢，造成连接池满了
redis服务端由于一些原因造成了客户端命令执行过程的阻塞
2.2 客户端读写超时
java.net.SocketTimeoutException: Read timed out
读写超时时间设置过短
命令本身就是慢查询
客户端与服务端网络不正常
redis发生阻塞
2.3 客户端连接超时
java.net.SocketTimeoutException: connect timed out
连接超时时间设置过短
redis发生阻塞，造成tcp-backlog已满，造成新连接失败
网络问题
2.4 客户端缓冲区异常
Unexpected end of stre
输出缓冲区满，如输出缓冲区设置为1m1m60，那么get一个2M的bigkey，就会出现这个异常
长时间闲置连接而被服务器端主动断开
2.5 redis正在加载持久化文件
LOADING Redis is loading the dataset in memory
jedis调用redis时，如果redis正在加载持久化文件时。
2.6 redis使用的内存超过maxmemory
OOM command not allowed when used memory > 'maxmemory'
2.7 客户端连接数过大，超过了maxclients
ERR max number of clients reached
这个问题可能会比较棘手，因为此时无法执行Redis命令进行问题修复，一般来说可以从两个方面进行着手解决：
客户端下线部分应用，在通过查找程序bug或调整maxclients
如果是高可用或集群，服务端考虑将当前redis做故障转移
3. 故障案例
3.1 redis内存陡增
表现：redis主节点内存陡增，几乎用满maxmemory，而从节点很正常，客户端几乎都会产生OOM异常
原因：
需要查询主从节点的键数，如执行dbsize，看是否是主从复制出现问题
是否是输入输出缓冲区造成主节点内存陡增，执行info clients指令
解决方法：
执行client kill指令杀掉输出缓冲区大的连接
禁止开发层面使用如monitor命令，运维层面可以适当使用
限制输出缓冲区的大小
使用专业的redis运维工具，如cachecloud
3.2 客户端周期性的超时
表现：客户端周期性的出现大量超时，而服务端没有明显异常，只是有一些慢查询
定位问题：慢查询和周期性超时时间是否吻合，程序是否定期执行慢查询
解决方案：
运维层面，监控慢查询，一旦超过阈值，就发出警报
开发层面，控制批量查询的个数、时间复杂度高的指令
使用专业的运维工具，如cachecloud
总结：
因为redis是单线程架构模式，因此需要特别注意慢查询和时间复杂度高的指令，这会影响整个redis的并发，可能造成多种问题。