。

Redis采用单线程模型#xff0c;任何耗时操作都可能阻塞后续请求#xff0c;导致整体性能下降。

根据Redis的核心机制#xff0c;命令执行流程可分为以下步骤…慢查询指在Redis中执行时间超过预设阈值的命令其日志记录是排查性能瓶颈的核心工具。

Redis采用单线程模型任何耗时操作都可能阻塞后续请求导致整体性能下降。

客户端发送命令

value序列化为Redis协议格式RESP通过Socket发送到服务器。

服务端接收与解析

服务器读取Socket数据到客户端的输入缓冲区querybuf解析出命令参数argv和argc然后放入命令的执行队列。

关键步骤命令合法性校验如参数个数、权限检查和查找命令表redisCommand

命令执行

根据命令在命令表中找到对应的实现函数如setCommand执行核心逻辑如数据读写。

唯一被慢查询记录的耗时阶段此阶段的执行时间微秒级会被记录到慢查询日志。

返回结果与清理

将执行结果写入客户端输出缓冲区通过Socket返回给客户端并清理缓冲区和连接状态。

核心配置参数

参数名默认值说明slowlog-log-slower-than10ms执行时间阈值微秒设为0记录所有命令负数则关闭记录slowlog-max-len128日志最大存储条数采用

FIFO

128生产建议阈值设为1ms1000μs日志长度≥512条以覆盖更多历史记录。

动态修改配置参数

上面的参数可以直接修改/etc/redis/redis.conf配置文件然后重启redis服务。

127.0.0.1:6379

512最后需要将配置持久化到配置文件中否则重启就恢复成默认配置参数了。

127.0.0.1:6379

timestamp命令执行时间戳duration耗时微秒command完整命令及参数

为了看到慢查询日志的效果我们这里先将slowlog-log-slower-than文件参数改为0这样所有的命令都会记录到慢查询中。

改为0记录所有命令

*、SORT、SUNION、ZUNIONSTORE尤其当数据量较大时会导致CPU资源消耗过高执行时间显著增加。

示例KEYS

问题对存储大量数据的Key如百万级列表、哈希表进行读写或删除操作如

DEL、GET会因内存分配/释放耗时过长而阻塞主线程BigKey可以通过命令redis-cli

--bigkeys

示例删除一个存储100万条数据的列表时直接使用DEL可能导致服务暂停。

问题大量Key在同一时间段过期触发Redis主动删除机制默认每100ms随机扫描20个Key若过期比例超过25%会循环扫描直至完成导致主线程阻塞。

持久化与后台进程影响

always或everysec频繁刷盘可能导致磁盘I/O压力增大影响主线程性能。

Fork操作执行RDB快照或AOF重写时fork子进程拷贝内存页表若实例内存过大如超过10GB会导致主线程阻塞耗时可能达秒级。

外部环境问题

网络延迟客户端与Redis服务器间的网络不稳定导致请求响应时间变长。

资源竞争CPU被其他进程占用Redis单线程依赖CPU或物理内存不足触发Swap交换降低性能。

命令与数据结构优化

避免高复杂度命令用SCAN替代KEYS客户端聚合数据替代SORT分页处理大数据如LRANGE分页读取。

拆分BigKey将大Key拆分为多个小Key如分片列表或使用渐进式删除通过Lua脚本分批次删除。

批量操作使用MGET、MSET减少网络往返或通过管道Pipeline合并多个命令。

配置调优

慢查询日志调整slowlog-log-slower-than建议

1ms和

开启lazy-free机制lazyfree-lazy-expire

根据业务需求选择AOF刷盘策略如everysec平衡性能与安全避免与RDB同时运行。

资源与环境优化

分散Key过期时间为Key的过期时间添加随机偏移避免集中过期例如expireat

key

GET或Prome***usGrafana监控内存、CPU、命令耗时等指标。

运维最佳实践