点一下关注吧！！！非常感谢！！持续更新！！！

🚀 AI 篇持续更新中！（长期更新）

AI 炼丹日志-30-新发布【1T 万亿】参数量大模型！Kimi‑K2 开源大模型解读与实践，持续打造实用 AI 工具指南！📐🤖

💻 Java 篇正式开启！（300 篇）

目前 2025 年 07 月 16 日更新到：Java-74 深入浅出 RPC Dubbo Admin 可视化管理 安装使用 源码编译、Docker 启动 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解

Redis 提供了类似 MySQL 的慢查询日志机制，用于记录执行时间超过指定阈值的命令，帮助开发者分析性能瓶颈与系统异常。通过配置 slowlog-log-slower-than 和 slowlog-max-len，可以精准控制记录策略。运维人员可使用 SLOWLOG GET 查看日志，快速定位慢命令及其影响。为进一步优化性能，可采取数据结构精简、避免大 Key 与全量命令、合理持久化配置、使用 Pipeline 批量操作等措施。此外，Redis 还支持 MONITOR 实时命令跟踪（不建议用于生产）及接入 Grafana + Prometheus + RedisExporter 的可视化监控系统，实现慢查询检测、告警与资源监控的闭环优化。

章节内容

上节完成了的内容如下：

• Redis 通过 Lua 功能进行扩展

• Lua 下载安装

• Lua 在 Redis 中的使用案例（多个）

Redis 慢查询详解

慢查询概念

MySQL 中有完善的慢查询日志机制，在 Redis 中同样提供了慢查询日志功能。Redis 慢查询日志用于记录执行时间超过指定阈值的命令请求，帮助开发人员和运维人员监控和优化 Redis 查询性能。

慢查询实现机制

Redis 使用一个先进先出(FIFO)的列表来存储慢查询日志，这种实现方式有以下几个特点：

1. 采用固定长度的队列结构

2. 当新记录超过最大长度时，最旧的记录会被自动移除

3. 查询效率高，O(1)时间复杂度

慢查询配置参数

在 redis.conf 配置文件中，有两个关键参数控制慢查询日志的行为：

1. slowlog-log-slower-than
   

2. 单位：微秒(1 秒=1000000 微秒)

3. 作用：设置命令执行时间的阈值

4. 取值说明：

5. 0：记录所有命令

6. <0：不记录任何命令

7. 0：只记录执行时间超过该值的命令

8. 默认值：10000 微秒(10 毫秒)

9. 生产环境建议：根据业务特点调整，通常设置为 1-10 毫秒

10. slowlog-max-len
    

11. 作用：设置慢查询日志的最大条数

12. 默认值：128 条

13. 建议值：根据内存情况和监控需求调整，通常设置为 1000-10000 条

配置示例

# 记录执行时间超过5毫秒的命令slowlog-log-slower-than 5000
# 保留最近1000条慢查询记录  slowlog-max-len 1000

慢查询查看方法

可以通过 Redis 命令行工具查看慢查询日志：

SLOWLOG GET [n]  # 获取最近的n条慢查询记录SLOWLOG LEN      # 获取当前慢查询日志条数SLOWLOG RESET    # 清空慢查询日志

应用场景

1. 性能问题排查：当发现 Redis 响应变慢时，检查慢查询日志找出耗时命令

2. 命令优化：识别需要优化的热点命令

3. 容量规划：分析命令执行时间分布，为扩容提供依据

4. 异常监控：通过定期检查慢查询日志发现异常查询模式

查询日志

为了方便测试，可以通过暂时设置的方式，将检查的阈值调低。

config set slowlog-log-slower-than 0config set slowlog-max-len 2

此时我们的操作基本上都会变成慢操作：

set name wzkset age 123get nameget age

我们查看慢日志内容：

slowlog get

日志可以用来解决以下问题：

• 问题诊断：当系统或应用程序出现问题时，日志提供的信息，帮助开发人员追踪和定位问题的根本原因。

• 性能优化：通过分析日志数据，可以了解系统的性能瓶颈和潜在问题，并采取相应的措施来优化系统的性能。

Redis 性能优化：定位与处理慢查询

慢查询定位与分析

1. 使用slowlog get命令获取 Redis 执行较慢的命令日志

2. 分析日志中的关键信息：执行时间、命令内容、发生时间等

3. 重点关注执行时间超过 10ms 的命令（可根据业务需求调整阈值）

具体优化措施

数据结构优化

• 精简键值设计：

• 使用简短且有意义的 Key 名称（如user:1001:profile而非user_profile_information_1001）

• 对于 Value 数据：

• 优先使用 int 类型（如存储数字 1000 而非字符串"1000"）

• 避免冗余数据存储

• 避免危险操作：

• 禁止使用keys *这种全量扫描命令（替代方案：使用 SCAN 命令分批次获取）

• 谨慎使用hgetall（替代方案：使用hmget获取指定字段或hscan分批次获取）

• 大 Key 处理：

• 将大 Value 拆分为多个小 Value（如将包含 1000 个元素的 List 拆分为 10 个 100 元素的 List）

• 使用分页查询代替全量获取

配置优化

• 持久化策略：

• 将 RDB 模式转换为 AOF 模式

• RDB 的潜在问题：

• 执行 fork 操作创建子进程可能阻塞主线程

• 在数据量大的情况下 fork 操作耗时较长

• AOF 优势：

• 以追加方式记录操作日志

• 可配置不同的 fsync 策略平衡性能与安全性

高效操作技巧

• 管道(Pipeline)技术：

• 适用场景：需要批量执行多个命令时

• 实现原理：将多个命令打包一次性发送，减少网络往返时间

• 示例：批量设置 100 个键值对时，管道可提升 10 倍以上性能

• 合理使用 Hash：

• 适合存储对象属性（如用户信息：hmset user:1001 name "John" age 30）

• 相比多个 String 键存储，Hash 能减少内存使用和网络开销

资源管理

• 内存限制：

• 设置maxmemory参数限制 Redis 最大内存使用量

• 配合maxmemory-policy配置内存淘汰策略

• 好处：

• 避免使用 swap 分区导致性能急剧下降

• 防止 OOM(Out Of Memory)错误导致服务崩溃

• 推荐设置为物理内存的 3/4，留出部分内存供系统使用

监控与持续优化

1. 定期检查 slowlog，分析新的性能瓶颈

2. 使用info memory监控内存使用情况

3. 对复杂查询考虑使用 Redis Lua 脚本优化

4. 在高并发场景下，考虑使用 Redis 集群分散压力

监视器 (MONITOR)

功能概述

Redis 的 MONITOR 命令允许客户端实时监控服务器接收和处理的所有命令请求。当一个客户端执行 MONITOR 命令后，它会变成一个监视器，持续接收并显示服务器执行的每个命令的详细信息。

工作原理

1. 执行 MONITOR 命令：客户端连接后只需发送简单的 MONITOR 命令即可进入监视模式。

2. 服务器行为变化：

3. 对于普通客户端，服务器正常处理命令请求

4. 对于监视器客户端，服务器会将所有接收到的命令转发给它们

5. 信息格式：每条监控信息包含以下内容：

6. 时间戳（精确到微秒）

7. 客户端连接的唯一标识符

8. 客户端来源 IP 和端口

9. 执行的 Redis 命令及其参数

使用示例

127.0.0.1:6379> MONITOROK1609459200.123456 [0 127.0.0.1:52345] "SET" "foo" "bar"1609459200.234567 [1 192.168.1.100:62834] "GET" "foo"

应用场景

1. 调试与开发：实时观察所有客户端命令，帮助诊断问题

2. 性能分析：监控命令执行频率和模式

3. 安全审计：记录所有操作用于安全审查

注意事项

1. 性能影响：MONITOR 会显著增加服务器负载，不应在生产环境长期使用

2. 信息量：高流量环境下会产生大量输出，可能导致网络拥塞

3. 权限控制：建议限制 MONITOR 命令的使用权限

关闭监视器

要退出监视模式，客户端可以：

1. 断开与服务器的连接

2. 发送 QUIT 命令

3. 或等待连接超时

替代方案

对于生产环境，考虑使用更轻量的方案：

• SLOWLOG 获取慢查询日志

• 配置文件中设置日志级别

• 使用 Redis 的 Pub/Sub 机制实现定制化监控

• 

客户端 1

./redis-climonitor

客户端 2

./redis-cliset name:001 wzkset name:002 kangkangset age:001 12set age:002 33

Redis 监控平台方案详解

Redis 作为高性能的内存数据库，在生产环境中需要全面的监控来确保其稳定性和性能。以下是几种主流的 Redis 监控解决方案：

1. Grafana

Grafana 是一个开箱即用的可视化工具，具有以下特点：

• 功能齐全的度量仪表盘：提供丰富的预置 Redis 监控面板模板

• 灵活的图形编辑器：支持自定义图表样式和布局

• 多数据源支持：可同时接入 Prometheus、InfluxDB 等多种数据源

• 告警功能：支持设置阈值告警并通过邮件、Slack 等渠道通知

典型应用场景：需要快速搭建可视化监控系统，且对 UI 美观度要求较高的场景。

2. Prometheus

Prometheus 是一个开源的监控系统，专门用于记录实时指标：

• 数据采集机制：通过 HTTP 协议主动拉取目标上的指标数据

• 本地时序数据库：高性能的 TSDB 存储方案

• 强大的查询语言：PromQL 提供灵活的数据查询能力

• 多维数据模型：支持通过标签进行多维度数据聚合

部署架构：Prometheus Server + RedisExporter + Grafana（可选）

3. RedisExporter

RedisExporter 是专为 Prometheus 设计的 Redis 指标导出工具：

• 指标收集：采集 Redis 的关键性能指标（内存使用、命令统计、连接数等）

• 指标转换：将 Redis 的 INFO 命令输出转换为 Prometheus 格式

• 轻量级：作为独立的守护进程运行，资源消耗低

配置示例：

./redis_exporter \  -redis.addr=redis://localhost:6379 \  -web.listen-address=:9121

4. 综合监控方案

推荐的完整监控架构：

Redis实例 → RedisExporter → Prometheus → Grafana

这种组合提供了：

1. 数据采集（RedisExporter）

2. 数据存储和告警（Prometheus）

3. 可视化展示（Grafana）

典型监控指标包括：

• 内存使用率

• 命令执行次数

• 连接数

• 键空间使用情况

• 持久化状态

• 复制状态（主从架构下）