Redis客户端

Redis客户端与服务器端之间的通信协议是在TCP协议之上构建的。Redis指定了RESP(Redis序列化协议)实现客户端与服务端的交互。

RESP发送命令的格式如下:

*<参数数量> CRLF

$<参数1的字节数量> CRLF

<参数1> CRLF

...

$<参数N的字节数量> CRLF

<参数N> CRLF

RESP返回结果的格式分为五种:

  • 状态回复:在RESP中第一个字节为+
  • 错误回复:在RESP中第一个字节为-
  • 整数回复:在RESP中第一个字节为:
  • 字符串回复:在RESP中第一个字节为$
  • 多条字符串回复:在RESP中第一个字节为*

如果回复的消息中有nil值,那么返回的是$-1

直连方式每次都会新建TCP连接,且无法限制Jedis对象的个数,可能造成连接泄漏。使用连接池可以避免,只有少量的并发同步开销。

Jedis中的eval方法、evalsha方法、scriptLoad方法可以执行Lua脚本。

client list命令能列出与Redis服务端相连的所有客户端连接信息。

Redis案例分析

现象:

  • 服务端Redis主节点内存陡增,几乎用满maxmemory。而从节点内存并没有变化。
  • 客户端产生了OOM异常,也就是Redis主节点使用的内存已经超出了maxmemory设置,无法写入新的数据。

分析可能原因:

  • 确实有大量写入,但是主从复制出现问题。(经查,排除)
  • 其他原因造成主节点内存使用过大。(排查是否由客户端缓冲区造成主节点内存陡增,使用info clients命令查询。发现输出缓冲区不正常,查找后发现由客户端在执行monitor命令造成的。)

处理方法:使用client kill命令杀掉连接。

如何及时发现和避免类似问题:运维层面禁止monitor命令(可以使用rename-command命令重置monitor命令为一个随机字符串)。从开发层面进行培训。限制输出缓冲区的大小。使用专业的Redis运维工具,如CacheCloud。

现象:

  • 客户端出现大量超时,分析发现是周期性出现的。
  • 服务端没有明显异常,只是有一些慢查询操作。

分析可能原因:

  • 网络原因:网络出现周期性问题,经过观察网络是正常的。
  • Redis本身原因:查看日志,没有异常。
  • 客户端原因:由于是周期性出现问题,就和慢查询日志的里氏记录对应了一下时间,发现只要慢查询出现,客户端就会产生大量连接超时。最终发现是应用方有个定时任务,每5分钟执行一次hgetall操作。

如何及时发现和避免类似问题:

运维层面进行监控慢查询,一旦出现问题,发出报警。

从开发层面,让开发人员加强对Redis的理解,避免不正确的使用方式。

使用专业的Redis运维工具,如CacheCloud。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值