redis频繁自动停止主因是oom killer强制终止，需先通过dmesg确认，再设置maxmemory和淘汰策略，并清理残留pid文件，最后辅以监控脚本兜底。
宝塔面板里 Redis 频繁自动停止，不是服务没配好，而是它已经被系统 kill 掉了——绝大多数情况是 OOM Killer 干的。直接修脚本或加定时重启只是掩耳盗铃，得先稳住内存，再补监控兜底。
查 Redis 是不是被 OOM Killer 杀掉的
这是最常被跳过的一步。Redis 进程消失但没报错？大概率是内核强制终止的。执行以下命令确认：
sudo dmesg -T | grep -i "killed process" | grep redis
如果输出类似 Killed process 12345 (redis-server)，就坐实了 OOM。此时再调 service redis restart 只是临时救火。
- 检查当前内存压力：
free -h和cat /proc/meminfo | grep -i "oom\|commit" - Redis 默认不限制内存（
maxmemory未设），数据一涨就触发 OOM - 别只看宝塔监控里的“内存使用率”，要盯
Available值是否长期低于 500MB
必须设置 maxmemory 和淘汰策略
不设 maxmemory 的 Redis 在宝塔环境等于裸奔。配置文件 /www/server/redis/redis.conf 里至少补这两行：
maxmemory 512mb maxmemory-policy allkeys-lru
数值不是拍脑袋定的：留出至少 1GB 给系统和其他服务（如 Nginx、MySQL），剩余内存的 60%～70% 给 Redis。例如 4GB 总内存，maxmemory 设 1.5gb 更稳妥。
-
allkeys-lru比volatile-lru更适合宝塔默认部署场景（没手动设 TTL 的 key 也参与淘汰） - 改完必须重启：
service redis restart，否则配置不生效 - 避免用
noeviction—— 写满就拒绝请求，比崩溃还难排查
用计划任务做被动兜底（不是主方案）
仅当确认 Redis 能手动启动、且已限制内存后，才加这层保险。别把它当第一选择。
写一个检测脚本 /www/server/redis/check_redis.sh：
#!/bin/bash
if ! pgrep -x "redis-server" > /dev/null; then
echo "$(date): Redis down, restarting..." >> /var/log/redis_monitor.log
service redis start
fi
- 给执行权限：
chmod +x /www/server/redis/check_redis.sh - 在宝塔「计划任务」里添加：类型选「Shell 脚本」，周期设「每 3 分钟」，脚本路径填完整路径
- 日志路径
/var/log/redis_monitor.log要提前创建并确保 redis 用户有写权限
注意 redis.pid 文件残留导致假死
Redis 进程没了但 /www/server/redis/redis.pid 还在，会导致 service redis start 失败（提示“already running”）。这不是 bug，是设计如此。
- 手动清理命令：
rm -f /www/server/redis/redis.pid - 不要在计划任务脚本里无条件删 pid 文件——得先判断进程真死了再删
- 更稳妥的做法是在脚本里加一句：
if [ -f /www/server/redis/redis.pid ] && ! kill -0 $(cat /www/server/redis/redis.pid) 2>/dev/null; then rm -f /www/server/redis/redis.pid; fi
真正稳定的 Redis 不靠重启脚本兜底，而靠 maxmemory 卡死上限、ulimit -n 放开文件描述符、以及定期看 /www/server/redis/redis.log 里有没有 MISCONF 或 Can't save in background 这类持久化报错。这些点漏掉任何一个，定时脚本都只是把崩溃延迟几分钟而已。
