Redis 生产环境运维指南（持续更新）
前言
Redis 是什么？
Redis 就像一个超级快的记事本。普通的记事本保存在硬盘上，读取速度慢；但 Redis 把数据保存在内存里（内存就像大脑的记忆，存取速度极快），所以它能在毫秒级别响应你的请求。
正是因为 Redis 速度快，它经常被用来做：缓存（把常用数据放这里，加快访问速度）、计数器（点赞数、浏览量）、会话存储（用户登录状态）等。
Redis 是互联网公司最常用的组件之一。作为运维工程师，我们的职责是：让它稳如老狗、快如闪电。
这篇文章会告诉你：
- 怎么部署一个可靠的 Redis
- 生产环境要看哪些指标
- 内存满了怎么办
- 数据怎么备份才安全
- 出问题了怎么排查
目录
快速部署 Redis
Docker 是什么？
Docker 就像集装箱
想象一下：你在盖房子，需要把建材（代码、依赖、环境）都装进集装箱（容器）。有了集装箱，不管在哪里（哪台服务器），只要有吊车（Docker），就能快速搭建起同样的房子。
这就是 Docker 的魔力：一次打包，到处运行。
用 Docker 部署 Redis
一条命令就能启动 Redis：
docker run -d \
--name redis-demo \
-p 6379:6379 \
redis:7.2.14
命令解释：
| 参数 | 含义 | 通俗解释 |
|---|---|---|
docker run |
启动一个容器 | 相当于"启动一台虚拟机" |
-d |
后台运行 | 不占用当前终端 |
--name redis-demo |
给容器起个名字 | 方便识别和管理 |
-p 6379:6379 |
端口映射 | 把容器里的 6379 端口暴露出来，让外部能访问 |
redis:7.2.14 |
使用哪个镜像 | 指定版本，就像指定软件版本号 |
验证 Redis 是不是正常
docker exec redis-demo redis-cli ping
docker exec redis-demo：在 redis-demo 这个容器里执行命令redis-cli ping：Redis 自带的测试命令
如果一切正常，会输出 PONG，就像你对着山谷喊"你好"，山谷回你"你好"一样。
生产环境推荐配置
生产环境不能像测试那样随便启动，需要考虑数据持久化、内存限制等：
docker run -d \
--name redis-prod \
-p 6379:6379 \
-v /data/redis:/data \ # 把容器的 /data 目录映射到宿主机的 /data/redis
redis:7.2.14 \
redis-server \
--appendonly yes \ # 开启数据持久化（AOF）
--maxmemory 2gb \ # 最多只能用 2GB 内存
--maxmemory-policy allkeys-lru \ # 内存满了就淘汰最少使用的 key
--save 900 1 \ # 每15分钟备份一次
--save 300 10 \ # 每5分钟备份一次（如果有10次改动）
--save 60 10000 # 每1分钟备份一次（如果有10000次改动）
生产环境为什么要这么配置？
- 不指定内存限制？小心被 OOM（内存溢出）杀掉
- 不开持久化？服务器重启后数据全丢
- 不设淘汰策略？内存满了 Redis 就罢工不干活
核心监控指标详解
INFO 命令 - Redis 的"体检报告"
什么是 INFO 命令？
想象一下，你去医院体检，医生会给你量血压、测血常规、做心电图。INFO 命令就是给 Redis 做"体检"的，它会返回 Redis 的各项身体指标。
有了这些指标，我们就能知道 Redis 有没有"生病"（出问题）。
redis-cli INFO
输出会分成很多"段落"（section），每个段落管一类指标：
redis-cli INFO memory # 内存指标 - 查看内存使用情况
redis-cli INFO stats # 统计指标 - 查看请求量和命中率
redis-cli INFO persistence # 持久化指标 - 查看备份状态
redis-cli INFO clients # 客户端指标 - 查看连接数
redis-cli INFO cpu # CPU指标 - 查看CPU使用情况
redis-cli INFO replication # 复制指标 - 查看主从同步状态
关键指标速查表
| 指标分类 | 关键指标 | 人话解释 | 正常范围 |
|---|---|---|---|
| 内存 | used_memory |
Redis 现在用了多少内存 | < 80% 的 maxmemory |
| 内存 | mem_fragmentation_ratio |
内存碎片率，越高说明浪费越多 | < 1.5 |
| 内存 | evicted_keys |
因为内存满了被踢掉的 key 数量 | 应该是 0 或接近 0 |
| 连接 | connected_clients |
现在有多少个客户端连着 | < maxclients（通常是10000） |
| 连接 | blocked_clients |
有多少客户端在等待（卡住了） | 应该是 0 |
| 性能 | instantaneous_ops_per_sec |
每秒处理多少个请求 | 根据业务定，越高越好 |
| 性能 | keyspace_hits / keyspace_misses |
缓存命中/未命中次数 | 命中率 > 90% |
| 持久化 | rdb_last_bgsave_status |
RDB 备份有没有成功 | 应该是 ok |
| 持久化 | aof_last_write_status |
AOF 写入有没有成功 | 应该是 ok |
| 延迟 | latest_fork_usec |
上次 fork 用了多久（fork 会导致短暂卡顿） | < 1秒 |
内存管理
为什么要关注内存？
Redis 是"内存数据库"
就像你的手机 RAM（运行内存）越大，能同时开的应用越多，手机越流畅。Redis 也是一样，它把所有数据都放在内存里，所以特别快。
但内存是有限的！如果你的手机只剩 1% 的内存，就会变得卡卡的。Redis 也是一样，内存用满了就会出问题。
内存指标解读
查看内存使用情况：
redis-cli INFO memory
核心指标详解：
| 指标 | 通俗解释 | 运维要关注什么 |
|---|---|---|
used_memory |
Redis 自己"认为"自己用了多少内存 | 监控增长趋势，如果一直涨就要小心 |
used_memory_rss |
操作系统实际分配给 Redis 的内存 | 如果比 used_memory 大很多，说明有内存碎片 |
used_memory_peak |
历史最高内存使用量 | 用来评估需要多大内存 |
mem_fragmentation_ratio |
内存碎片率 | 太高（>1.5）说明内存浪费严重 |
maxmemory |
你给 Redis 设的内存上限 | 生产环境必须设置！ |
maxmemory_policy |
内存满了怎么办 | 根据业务选择合适的策略 |
内存碎片率分析
mem_fragmentation_ratio = used_memory_rss / used_memory
什么是内存碎片？
想象你有一张桌子（内存），上面放了很多书（数据）。如果你把书一本一本横着放，中间会有很多缝隙（碎片）。虽然书只占了一半的地方，但整张桌子都被占满了。
Redis 也是一样，虽然实际数据只有 1GB，但操作系统可能分配了 2GB 的空间给它，这就是碎片。
碎片率解读：
| 碎片率 | 状态 | 怎么办 |
|---|---|---|
| < 1.0 | 异常！用了虚拟内存 | 检查是不是在用 swap，很危险 |
| 1.0 - 1.5 | 正常 | 继续保持 |
| > 1.5 | 碎片太多 | 考虑重启或开启主动碎片整理 |
内存淘汰策略（重点！）
什么是淘汰策略？
就像你的手机内存满了，你再打开新 App，系统会自动关闭后台不常用的 App。Redis 也是一样，当内存满了，新的数据写不进来了，怎么办？
通过
maxmemory_policy可以设置：当内存满了，淘汰哪些数据。
| 策略 | 通俗解释 | 什么时候用 |
|---|---|---|
noeviction |
不淘汰，但写入会报错 | 数据特别重要，一点都不能丢 |
allkeys-lru |
淘汰最久没用的 key | 最推荐！ 缓存场景首选 |
volatile-lru |
只淘汰"有过期时间"的 key 中最久没用的 | 混合使用场景 |
allkeys-random |
随机淘汰一个 key | 没什么访问规律 |
volatile-ttl |
淘汰快要过期的 key | 有明确的 TTL 需求 |
volatile-random |
随机淘汰一个有过期时间的 key | 特定场景 |
通俗解释 LRU：
LRU = Least Recently Used（最近最少使用）
想象你有一个书架（内存），满了。你把一本很久没看的书拿出来，把新书放进去。LRU 就是这个道理：谁很久没被访问，就淘汰谁。
生产环境推荐配置：
CONFIG SET maxmemory 2gb # 限制最多用 2GB 内存
CONFIG SET maxmemory-policy allkeys-lru # 内存满了就淘汰最少使用的 key
为什么要设置 maxmemory？
不设置的话，Redis 会一直吃内存，直到被操作系统OOM杀掉。这就像没有上限的信用卡，很危险！
监控内存驱逐
redis-cli INFO stats | grep evicted
输出：
evicted_keys:0 # 被踢掉的 key 数量
evicted_clients:0 # 因为内存不够被断开的客户端
什么是 evicted_keys？
就像你的手机后台同时运行着微信、抖音、淘宝…当内存不够时，系统会自动关掉一个 app。evicted_keys 就是被"关掉"的 key 的数量。如果这个数字一直在涨，说明你的内存不够用，需要：
- 增加内存
- 减少存储的数据量
- 优化数据结构（有些 key 特别大）
持久化策略
什么是持久化？
简单来说，持久化就是把内存中的数据保存到硬盘上。Redis 的数据默认存储在内存中，但内存断电后数据会丢失（就像手机没电后 RAM 里的东西都没了）。
持久化就是为了解决这个问题——把数据保存到硬盘，即使服务器重启也能恢复数据。
Redis 提供两种持久化机制：RDB（快照） 和 AOF（追加日志）。它们可以单独使用，也可以同时使用。
RDB 持久化（快照方式）
什么是 RDB？
RDB 就像给 Redis 数据拍"照片"。它会定期把某个时刻的所有数据打包成一个文件保存到硬盘。
举个例子：
就像你玩单机游戏，每隔一段时间会自动存档。即使下次开机时出了什么问题，你也可以从存档恢复，不会丢失太多进度。
工作原理：
- Redis 会定期（按配置）fork 一个子进程
- 子进程负责把内存数据写入到 RDB 文件
- 写完后替换原来的 RDB 文件
RDB 的优缺点
| 优点 | 缺点 |
|---|---|
| 文件紧凑（经过压缩） | 可能丢失最后一次快照后的数据 |
| 恢复速度快 | fork 大数据集时可能阻塞（尤其数据量大时） |
| 适合备份 | 无法实时持久化 |
配置示例
# 触发条件：时间 + 修改次数
# 格式：save 秒钟 次数
save 900 1 # 900秒（15分钟）内至少1次修改则保存
save 300 10 # 300秒（5分钟）内至少10次修改则保存
save 60 10000 # 60秒（1分钟）内至少10000次修改则保存
通俗解释：
save 900 1的意思是：如果过去 15 分钟内有至少 1 次数据修改，就保存一次- 这样可以保证：即使 Redis 崩溃，最多丢失 15 分钟的数据
监控 RDB 状态
redis-cli INFO persistence | grep rdb
关键指标：
rdb_last_bgsave_status:ok # 最近一次保存是否成功（ok = 成功）
rdb_last_bgsave_time_sec:0 # 最近一次保存用了多少秒
rdb_bgsave_in_progress:0 # 是否正在保存（0=没有，1=正在保存中）
rdb_changes_since_last_save:5 # 自上次保存后又修改了多少次
AOF 持久化（日志方式）
什么是 AOF？
AOF 就像记账本。Redis 每次执行写命令（SET、LPUSH 等）时，都会把这个命令"记账"记录到文件末尾。
举个例子：
就像公司的流水账，每做一笔交易就记一笔。如果公司倒闭了，你可以通过账本把交易记录重新跑一遍，恢复到某个状态。
工作原理：
- 每次执行写命令时，把命令追加到 AOF 文件
- 重启时，重新执行一遍 AOF 文件中的命令来恢复数据
AOF 的优缺点
| 优点 | 缺点 |
|---|---|
| 数据安全度高（每秒同步最多丢1秒数据） | 文件体积比 RDB 大 |
| 日志文件可读（可以用 cat 查看） | 恢复速度比 RDB 慢 |
| 写入性能有一定影响 |
配置示例
appendonly yes # 开启 AOF 持久化
appendfsync everysec # 同步频率：每秒同步一次（推荐）
# appendfsync always # 每次写操作都同步（最安全，但最慢）
# appendfsync no # 由操作系统决定（最快，但最不安全）
auto-aof-rewrite-percentage 100 # AOF 文件比上次大 100% 时触发重写
auto-aof-rewrite-min-size 64mb # AOF 文件至少 64MB 时才触发重写
appendfsync 选项解释：
| 选项 | 含义 | 通俗解释 | 安全性 | 性能 |
|---|---|---|---|---|
always |
每次写操作都同步 | 每次下单立即记账 | 最高（最多丢1条数据） | 最差 |
everysec（推荐） |
每秒同步一次 | 每小时对一次账 | 高（最多丢1秒数据） | 中等 |
no |
操作系统决定 | 什么时候想起来了再记 | 低（可能丢很多） | 最好 |
监控 AOF 状态
redis-cli INFO persistence | grep aof
关键指标：
aof_enabled:1 # AOF 是否开启（1=开启，0=关闭）
aof_last_write_status:ok # 最近一次写入是否成功
aof_rewrite_in_progress:0 # 是否正在重写（0=没有，1=正在重写）
aof_current_size:1024 # 当前 AOF 文件大小（字节）
RDB 和 AOF 可以同时开启吗？
完全可以！而且生产环境通常建议同时开启！
同时开启的好处
| 组合方式 | 通俗解释 | 适用场景 |
|---|---|---|
| 同时开启 RDB + AOF | 双重保险 | 生产环境推荐！ |
| 仅开启 RDB | 存档但不记流水 | 数据丢了可以接受，只求恢复快 |
| 仅开启 AOF | 只记流水不存档 | 数据不能丢，但恢复慢点也能接受 |
为什么推荐同时开启？
- 数据安全最大化：即使 AOF 写坏了，还可以用 RDB 恢复
- 恢复速度快：优先用 RDB 快速恢复，再用 AOF 补齐增量数据
- 互相备份：两种方式可以互相作为备份
同时开启时的加载顺序
Redis 重启时，如果同时开启了 RDB 和 AOF，会优先使用 AOF 恢复数据，因为 AOF 数据更完整。
生产环境推荐配置
高可靠性场景（推荐）：
appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000
纯缓存场景（不需要持久化）：
appendonly no
save "" # 禁用 RDB
maxmemory-policy allkeys-lru # 内存满了就淘汰
纯缓存场景是什么意思？
有些业务用 Redis 只是为了"加速"，数据丢了可以从数据库重新加载，不需要 Redis 来"保管"数据。这时候可以不用持久化，省资源。
性能监控
命令执行统计
redis-cli INFO stats
关键性能指标：
| 指标 | 通俗解释 |
|---|---|
instantaneous_ops_per_sec |
现在每秒钟能处理多少请求（越高越好） |
total_commands_processed |
从启动到现在一共处理了多少请求 |
keyspace_hits |
查缓存时，找到了多少次（命中） |
keyspace_misses |
查缓存时，没找到多少次（没命中） |
缓存命中率（非常重要！）
什么是缓存命中率？
想象你去图书馆借书：
- 命中率 = 你要的书在图书馆里能直接借到的概率
- 命中率 100% = 你要的书每次都在，不用去书架找
- 命中率 0% = 你要的书从来不在，得现去书架找
Redis 也是一样，命中率越高，说明缓存效果越好。
命中率 = keyspace_hits / (keyspace_hits + keyspace_misses) * 100%
运维建议：
| 命中率 | 状态 | 怎么办 |
|---|---|---|
| > 90% | 非常好 | 继续保持 |
| 80% - 90% | 还行 | 可以接受 |
| < 80% | 不太好 | 需要优化：增加内存、优化缓存key设计、检查业务逻辑 |
慢查询日志（定位问题）
什么是慢查询？
就像去医院看病，医生给你量体温（水银温度计），需要5分钟才能出结果。在这5分钟里，你只能等待。
慢查询就是那些执行时间"太长"的命令。正常命令可能 1 毫秒就完成了，但有些命令可能需要 1 秒甚至更久，这些就是"慢查询"。
配置慢查询阈值：
# 超过 10 毫秒的命令就记录下来
CONFIG SET slowlog-log-slower-than 10000 # 单位是微秒，10000 = 10毫秒
# 最多记录 128 条
CONFIG SET slowlog-max-len 128
查看慢查询：
redis-cli SLOWLOG GET 10 # 获取最近 10 条慢查询
输出示例：
1) 1) (integer) 0 # 日志ID（从0开始编号）
2) (integer) 1780397852 # 时间戳（可以换算成日期时间）
3) (integer) 15 # 执行耗时（15微秒 = 0.015毫秒）
4) 1) "SET" # 执行的命令
2) "test_key"
3) "hello world"
常见导致慢查询的原因：
- 大 key：一个 key 存了几MB甚至几GB的数据
- 复杂命令：比如 SORT、LREM 等需要遍历数据的命令
- **keys ***：遍历所有 key，在数据量大时会非常慢（生产环境禁用！）
- 持久化操作：RDB/AOF 写入时可能会短暂变慢
延迟监控
什么是延迟？
延迟就像点外卖的"预计送达时间"。你11:00下单，预计11:30送达，延迟就是30分钟。
Redis 的延迟就是：从你发命令到收到响应的时间。正常应该是亚毫秒级（< 1毫秒），如果变成几十毫秒甚至几百毫秒，说明有问题。
Redis 7 提供了延迟监控功能：
# 设置延迟监控阈值（毫秒）
CONFIG SET latency-monitor-threshold 100
# 查看最近有没有延迟问题
redis-cli LATENCY LATEST
# 查看某个命令的延迟历史
redis-cli LATENCY HISTORY command-name
客户端连接管理
查看客户端连接
什么是客户端连接？
就像你去银行办业务，需要取号（建立连接），办完业务后把号还回去（断开连接）。
Redis 也是一样，你的应用程序要连接 Redis，就需要建立一个"连接"。如果连接数太多，Redis 会忙不过来。
redis-cli CLIENT LIST # 查看所有连接
输出示例：
id=8 addr=127.0.0.1:38306 laddr=127.0.0.1:6379 fd=8 name= age=0 idle=0 flags=N db=0
字段解读（通俗版）：
| 字段 | 通俗解释 |
|---|---|
id |
客户的排队编号（8号） |
addr |
客户从哪里来（IP:端口） |
age |
来了多久了（秒） |
idle |
发呆多久了（秒） - 如果很高说明连接占着不干活 |
flags |
客户类型（N=普通，S=从节点，M=主节点） |
cmd |
正在办什么业务（空的说明在等着） |
连接数监控
redis-cli INFO clients
关键指标：
connected_clients:1 # 现在有多少人排队
maxclients:10000 # 最多能接待多少人
blocked_clients:0 # 有多少人在等待（卡住了）
连接数太多会怎样？
就像银行只有5个窗口，但来了100个人办业务。后面的人就要等很久，严重的会超时失败。
连接超时配置
什么是连接超时？
就像银行的"过号作废"。你取了号但不去办业务，超过5分钟就作废别人可以用了。
设置超时就是为了：释放那些"占着茅坑不拉屎"的连接。
# 设置空闲连接超过 300 秒（5分钟）就自动断开
CONFIG SET timeout 300
为什么要设置超时？
有些应用的连接池配置不当，连接用完了不断开，越积越多。最后 Redis 被打爆，无法接受新连接。
生产环境最佳实践
1. 内存配置（必须！）
maxmemory 4gb # 最多只能用 4GB 内存
maxmemory-policy allkeys-lru # 内存满了淘汰最少使用的 key
不设置 maxmemory 会怎样？
Redis 会一直吃内存，直到被操作系统杀掉。这就像没有上限的信用卡，很危险！
2. 持久化配置
appendonly yes # 开启 AOF
appendfsync everysec # 每秒同步一次
save 900 1 # 15分钟备份一次
save 300 10 # 5分钟备份一次
save 60 10000 # 1分钟备份一次
3. 安全配置（重要！）
requirepass your_strong_password # 设置密码，不要用简单密码！
rename-command FLUSHALL "" # 禁用清空所有数据的命令
rename-command FLUSHDB "" # 禁用清空单个数据库的命令
rename-command CONFIG "" # 禁用修改配置的命令（可选）
为什么要禁用 FLUSHALL？
就像银行不能随便让人把所有钱都取走。FLUSHALL 会一次性删除所有数据，误操作后果很严重！
4. 性能配置
tcp-keepalive 300 # TCP 保活，每5分钟检查连接是否活着
timeout 300 # 空闲连接超过5分钟就断开
slowlog-log-slower-than 10000 # 超过10毫秒的命令记入慢查询
slowlog-max-len 128 # 最多记录128条慢查询
5. 监控配置
latency-monitor-threshold 100 # 延迟超过100毫秒就记录
常见问题排查
问题 1：内存碎片率高
现象： mem_fragmentation_ratio > 1.5
通俗解释： 就像你的房间（内存）里有很多杂物（碎片），实际没放多少东西，但空间都被占满了。
排查步骤：
redis-cli INFO memory | grep fragmentation
解决方案：
- 方案一：开启主动碎片整理
CONFIG SET activedefrag yes
CONFIG SET active-defrag-threshold-lower 10
CONFIG SET active-defrag-threshold-upper 100
- 方案二：重启 Redis（推荐）
就像大扫除，把东西重新整理一下，空间就出来了。计划内维护时重启 Redis 效果最好。
问题 2：缓存命中率低
现象： 命中率 < 80%
通俗解释： 就像你去图书馆10次，只有2次能直接借到书，其他8次都要去书架现找。那这个图书馆的"缓存"就没意义了。
排查步骤：
redis-cli INFO stats | grep keyspace
解决方案：
- 分析 key 过期策略是否合理
- 检查是否有过多的短 TTL key（刚放进去就过期了）
- 增加内存容量（书架太小当然放不下）
- 优化业务缓存逻辑（是不是缓存策略有问题）
问题 3：连接数异常增长
现象： connected_clients 持续增长
通俗解释： 就像银行门口排队的人越来越多，但窗口还是那么几个。
排查步骤：
redis-cli CLIENT LIST # 看看都是谁在连接
解决方案：
- 检查应用连接池配置
看看应用是不是每次请求都新建连接，用完不断开（正确的做法是用连接池复用连接）
- 设置连接超时
CONFIG SET timeout 300 # 5分钟没活动就断开
- 手动清理空闲连接
redis-cli CLIENT KILL TYPE normal # 杀掉所有普通客户端连接
问题 4：持久化失败
现象： rdb_last_bgsave_status:err 或 aof_last_write_status:err
通俗解释： 就像存档失败了，这次玩游戏的进度白打了。
排查步骤：
redis-cli INFO persistence
解决方案：
- 检查磁盘空间 - 硬盘满了没空间写文件
df -h # 查看磁盘使用情况
- 检查磁盘 I/O 性能 - 硬盘太老了，写入太慢
iostat -x 5 # 查看磁盘IO情况
- 检查文件权限 - 有没有权限写文件
ls -la /data/ # 查看数据目录权限
- 查看 Redis 日志 - 看看具体报错信息
问题 5：响应延迟高
现象： 响应时间明显变长，原来1毫秒现在变成100毫秒
通俗解释： 就像银行办事突然变慢了，原来5分钟能办完，现在要1小时。
排查步骤：
# 1. 查看慢查询
redis-cli SLOWLOG GET 20
# 2. 查看延迟事件
redis-cli LATENCY LATEST
# 3. 查看CPU使用
redis-cli INFO cpu
解决方案：
- 检查是否有大 key 操作
就像一次性取很多现金会很慢，一次性操作很多数据也会慢
- 检查是否在执行持久化
RDB/AOF 在写入时会影响性能，尽量在业务低峰期做
- 检查 CPU 使用情况
CPU 100% 的时候 Redis 也快不起来
- 优化数据结构
避免一个 key 存放过大的数据（比如几MB的字符串）
监控脚本示例
简单监控脚本（直接可用）
#!/bin/bash
HOST="localhost"
PORT="6379"
echo "=========================================="
echo " Redis 监控报告"
echo "=========================================="
echo "时间: $(date)"
echo ""
echo "📊 【内存状态】"
redis-cli -h $HOST -p $PORT INFO memory | grep -E "used_memory_human|mem_fragmentation_ratio|maxmemory_human"
echo ""
echo "🔌 【连接状态】"
redis-cli -h $HOST -p $PORT INFO clients | grep -E "connected_clients|blocked_clients|maxclients"
echo ""
echo "⚡ 【性能指标】"
redis-cli -h $HOST -p $PORT INFO stats | grep -E "instantaneous_ops_per_sec|keyspace_hits|keyspace_misses"
echo ""
echo "💾 【持久化状态】"
redis-cli -h $HOST -p $PORT INFO persistence | grep -E "rdb_last_bgsave_status|aof_last_write_status"
echo ""
echo "📁 【数据统计】"
redis-cli -h $HOST -p $PORT DBSIZE
echo "=========================================="
保存为 redis-monitor.sh，然后：
chmod +x redis-monitor.sh
./redis-monitor.sh
总结
运维最需要关注的指标
| 关注点 | 核心指标 | 通俗解释 |
|---|---|---|
| 内存 | used_memory, mem_fragmentation_ratio | 别撑到了 |
| 连接 | connected_clients, blocked_clients | 别累到了 |
| 性能 | ops_per_sec, 缓存命中率 | 别闲着了 |
| 持久化 | rdb/aof 状态 | 别丢数据了 |
| 延迟 | slowlog, latency | 别卡住了 |
运维黄金法则
- 设置
maxmemory和淘汰策略 - 别让 Redis 失控 - 开启持久化 - 数据是命，不能丢
- 监控内存碎片率 - 碎片多了要整理
- 关注缓存命中率 - 命中率低要优化
- 定期检查慢查询 - 慢命令是隐患
- 建立完善的告警机制 - 出问题能第一时间知道
最后一句话总结：
Redis 是快的，但需要我们用心运维。让它吃适量的内存、连适量的客户端、持久化好数据、监控好指标，它就能稳如老狗、快如闪电！
持续更新中… 如有问题或建议，欢迎交流讨论！