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。