Redis检查怎么做？内存泄漏+连接故障排查全攻略，Redis内存泄漏与连接故障排查，全方位检查攻略
一、基础检查：确认Redis是否活着
凌晨三点突然收到报警短信？先别慌！用redis-cli ping命令试试水，如果返回"PONG"说明服务还在喘气。要是连这个都失败，赶紧执行ps aux | grep redis，看看进程是不是偷偷溜走了。去年双十一某电商平台就栽在这步，运维组愣是盯着空进程列表十分钟才反应过来断电了。
二、健康体检：INFO命令深度解析
输入redis-cli info就像给Redis拍CT，能扫出内存、连接数、持久化状态等30+项指标。重点关注这几个数据：
- used_memory_human：超过物理内存70%就该扩容了
- connected_clients：突增可能遭遇DDoS攻击
- keyspace_hits：命中率低于80%得优化缓存策略
某游戏公司曾因忽视rejected_connections数值，导致万人团战时卡成PPT，教训惨痛。
三、性能把脉：从入门到入土
用redis-benchmark -n 100000 -c 50做个压力测试，重点关注：
| 指标 | 健康值 | 危险信号 |
|---|---|---|
| QPS | >5万/秒 | <1万立即扩容 |
| 平均延迟 | <1ms | >10ms查慢查询 |
| 错误率 | 0% | >0.5%查网络或配置 |
遇到性能瓶颈别急着加机器，先查slowlog get 10看有没有慢查询作妖。某社交APP曾因一个O(N)的keys命令，让CPU飚到90%三天三夜。
四、内存泄露：看不见的吃钱黑洞
运行redis-cli --memkeys能揪出内存大户，配合config set maxmemory 4GB设个保险杠。警惕这些内存杀手：
- 忘记设置过期时间的会话缓存
- 用错数据结构（比如该用Hash却用String）
- 百万量级的 *** 未拆分
上个月某物流公司就因20GB的未过期运单数据，差点触发AWS天价账单。
五、高可用检查：给Redis上双保险
主从复制不是万金油，得定期执行redis-cli info replication确认：
- master_link_status是否up
- slave_repl_offset是否同步
- connected_slaves数量对不对
Sentinel监控要用redis-cli -p 26379 sentinel masters查看主节点状态。某金融系统曾因网络抖动导致脑裂，三节点互认主节点，直接损失千万级订单。
六、安全防线：别让数据库裸奔
执行redis-cli config get requirepass检查是否设密码，再用acl list看权限分配。必须封杀这些作 *** 操作：
- 公网开放6379端口
- 使用默认密码或空密码
- 未禁用FLUSHALL等高危命令
去年某创业公司Redis被黑，黑客勒索0.5个比特币才归还数据，血淋淋的教训。
七、灾备方案：今夜无眠保平安
每周用redis-cli bgsave做次RDB快照，再用info Persistence确认：
- rdb_last_bgsave_status是否ok
- aof_enabled是否开启
- aof_current_size是否正常增长
某在线教育平台曾因SSD故障丢失三天数据，就因没开AOF持久化。记住这个救命命令：redis-check-aof --fix appendonly.aof能修复大部分AOF文件损坏。
个人实战经验
搞了八年Redis运维，总结出三个必须凌晨三点检查的关键点：
- 大促期间每半小时看memory碎片率（info memory）
- 版本升级后重点监控客户端兼容性
- 跨机房同步必查网络延迟（redis-cli --latency）
最后送大家一句口诀：日常巡检按表走，故障排查倒着查，性能优化小步跑，容量规划留余地。按这个套路来，保你Redis稳如老狗！