redis 简单整理——客户端案例分析[十八]

前言

简单整理一下客户端案例分析。

正文

现象一:

服务端现象:Redis主节点内存陡增,几乎用满maxmemory,而从节点 内存并没有变化。

客户端现象:客户端产生了OOM异常,也就是Redis主节点使用的内存 已经超过了maxmemory的设置,无法写入新的数据.

2.分析原因

1)确实有大量写入,但是主从复制出现问题:查询了Redis复制的相关 信息,复制是正常的,主从数据基本一致。

redis 简单整理——客户端案例分析[十八]

2)其他原因造成主节点内存使用过大:排查是否由客户端缓冲区造成 主节点内存陡增,使用info clients命令查询相关信息如下:

redis 简单整理——客户端案例分析[十八]

很明显输出缓冲区不太正常,最大的客户端输出缓冲区队列已经超过了 20万个对象,于是需要通过client list命令找到omem不正常的连接,一般来 说大部分客户端的omem为0(因为处理速度会足够快),于是执行如下代 码,找到omem非零的客户端连接:

redis-cli client list | grep -v "omem=0"

redis 简单整理——客户端案例分析[十八]

已经很明显是因为有客户端在执行monitor命令造成的。

3.处理方法和后期处理

只要使用client kill命令杀掉这个连 接,让其他客户端恢复正常写数据即可。但是更为重要的是在日后如何及时 发现和避免这种问题的发生,基本有三点:

  1. 从运维层面禁止monitor命令,例如使用rename-command命令重置 monitor命令为一个随机字符串,除此之外,如果monitor没有做rename- command,也可以对monitor命令进行相应的监控

  2. 从开发层面进行培训,禁止在生产环境中使用monitor命令,因为有时 候monitor命令在测试的时候还是比较有用的,完全禁止也不太现实。

  3. 限制输出缓冲区的大小。

  4. 使用专业的Redis运维工具,上述问题在 Cachecloud中会收到相应的报警,快速发现和定位问题

现象二:

客户端周期性的超时

客户端现象:客户端出现大量超时,经过分析发现超时是周期性出现的.

服务端现象:服务端并没有明显的异常,只是有一些慢查询操作

原因:

·网络原因:服务端和客户端之间的网络出现周期性问题,经过观察网 络是正常的。

·Redis本身:经过观察Redis日志统计,并没有发现异常。

客户端:由于是周期性出现问题,就和慢查询日志的历史记录对应了 一下时间,发现只要慢查询出现,客户端就会产生大量连接超时,两个时间点基本一致.

redis 简单整理——客户端案例分析[十八]

redis 简单整理——客户端案例分析[十八]

最终找到问题是慢查询操作造成的,通过执行hlen发现有200万个元 素,这种操作必然会造成Redis阻塞,通过与应用方沟通了解到他们有个定 时任务,每5分钟执行一次hgetall操作。

hlen user_fan_hset_sort

以上问题之所以能够快速定位,得益于使用客户端监控工具把一些统计 数据收集上来,这样能更加直观地发现问题,如果Redis是黑盒运行,相信 很难快速找到这个问题。处理线上问题的速度非常重要。

处理方法和后期处理:

这个问题处理方法相对简单,只需要业务方及时处理自己的慢查询即 可,但是更为重要的是在日后如何及时发现和避免这种问题的发生,基本有三点:

  1. ·从运维层面,监控慢查询,一旦超过阀值,就发出报警。

  2. ·从开发层面,加强对于Redis的理解,避免不正确的使用方式。

  3. ·使用专业的Redis运维工具

总结

  1. RESP(Redis Serialization Protocol Redis)保证客户端与服务端的正 常通信,是各种编程语言开发客户端的基础。

  2. 客户端输入缓冲区不能配置,强制限制在1G之内,但是不会受到 maxmemory限制

  3. 客户端输出缓冲区支持普通客户端、发布订阅客户端、复制客户端 配置,同样会受到maxmemory限制。

  4. Redis的timeout配置可以自动关闭闲置客户端,tcp-keepalive参数可 以周期性检查关闭无效TCP连接

  5. monitor命令虽然好用,但是在大并发下存在输出缓冲区暴涨的可能性

  6. info clients帮助开发和运维人员找到客户端可能存在的问题。

  7. 理解Redis通信原理和建立完善的监控系统对快速定位解决客户端 常见问题非常有帮助

下一大节, 持久化相关知识。

上一篇:golang的一些测试技巧和工具


下一篇:程序运行时,如何输入EOF