Redis 监控
平台把 Redis 的运行指标做成了一屏仪表盘：版本与模式、内存与 CPU、Key 数量、网络吞吐，外加命令占比饼图和内存水位表盘。判断「缓存还撑不撑得住」看这一页就够。
功能在哪
- 菜单路径：基础设施 → 监控中心 → Redis 监控
- 路由地址：
/infra/monitors/redis - 数据来源：进入页面时调用一次后端缓存接口（
RedisApi.getCache()）拉取快照
页面不会自动刷新
指标是进入页面那一刻的快照，停留再久数字也不变。要看最新值，刷新浏览器页面即可。
界面认识
基本信息（12 项）
| 项 | 截图值示例 | 含义 |
|---|---|---|
| Redis版本 | 5.0.9 | 服务端版本 |
| 运行模式 | 单机 | 单机 / 集群 |
| 端口 | 6379 | 服务端口 |
| 客户端数 | 25 | 当前连接数，含后端连接池 |
| 运行时间(天) | 0 | 自启动以来天数 |
| 使用内存 | 1.00M | 真实内存占用，以它为准 |
| 使用CPU | 0.00 | CPU 占用率 |
| 内存配置 | 0B | maxmemory 上限；0B 表示未设上限 |
| AOF是否开启 | 否 | 追加文件持久化开关 |
| RDB是否成功 | ok | 最近一次快照持久化结果 |
| Key数量 | 13 | 当前键总数（含系统缓存键） |
| 网络入口/出口 | 12.32kps/ 5.63kps | 每秒入 / 出网络吞吐 |
两张图
- 命令统计（左，玫瑰饼图）：各命令调用占比，图例如 set / get / ping / scan / incrby / del / info / dbsize / exists / eval。
ping占比大属正常——客户端心跳即用 ping。 - 内存使用情况（右，表盘）：盘面刻度 0–50，中心文字（如
1.00M 内存消耗）才是真实内存值。
表盘指针只作示意
右图刻度上限固定为 50，指针位置是按该固定量程画的示意值；内存是否健康请读中心文字与基本信息「使用内存」，不要按指针读数判断。
常用操作
看内存水位
读基本信息「使用内存」+「内存配置」：配置为 0B 表示未设上限，内存随键增长；若设了上限，使用内存逼近上限时就要清理键或扩容。
看连接是否堆积
「客户端数」异常高于后端实例数 × 池大小时，可能存在连接未释放；结合「运行时间」判断是否刚重启。
看吞吐方向
「网络入口/出口」入口远大于出口多为写入密集，出口远大于入口多为读取 / 大 value 读取；突变时对照业务操作或 定时任务 的执行时刻。
看命令结构
饼图中 scan / dbsize 占比高说明有全库扫描类操作；eval 出现说明有 Lua 脚本调用。
视角对照
| 视角 | 能看到什么 |
|---|---|
| 任意登录用户（含租户管理员） | Redis 为后端全局组件，指标不区分租户，各视角一致 |
进阶
- AOF 与 RDB 的区别：AOF 追加每条写命令、重启重放，丢数据少但文件大；RDB 定时快照、恢复快但可能丢一个周期。截图部署为「AOF 否 + RDB ok」，即靠快照持久化。
- Key数量 包含系统键：会话、验证码、字典缓存、分布式锁等都占键数，与业务数据量不直接相等。
- 内存配置 0B 的风险：未设
maxmemory时 Redis 会吃到主机内存上限；生产建议设上限并配淘汰策略。 - 与 MySQL 监控分工：本页看缓存层，MySQL 监控 看数据库层；接口慢时两边对照可定位是哪一层。
- 快照对比法：需要观察趋势时，间隔刷新页面两次，比对「使用内存 / Key数量 / 网络入口出口」的差值。
常见问题
数字为什么不跳动？ 页面不自动刷新（见页首 info）。刷新浏览器即取新快照。
表盘指针指到 40 多，但使用内存才 1.00M？ 表盘量程固定 0–50 且指针为示意，读中心文字与基本信息「使用内存」（见页首 warning）。
运行时间(天) 为 0？ Redis 启动不足 24 小时，按天取整即 0；不代表异常。
内存配置 0B 是故障吗？ 不是，表示未设 maxmemory 上限；是否要设由部署策略决定。
Key数量 和我业务表的数据量对不上？ 键里包含会话、缓存、锁等系统键，且一个业务对象可能对应多个键或缺缓存时为零。
客户端数 25 正常吗？ 等于后端连接池 + 其他客户端的合计；只要不持续增长即正常。