redis-server --daemonize yes 命令虽可后台运行，但进程会随终端关闭退出；可靠方式是配置 redis.conf 中 daemonize yes、pidfile、logfile 和 dir 权限，并配合 systemd 使用 Type=forking 启动。
redis-server 启动时加 --daemonize yes 不起作用？
直接执行 redis-server --daemonize yes 确实能 fork 进后台，但进程会随终端关闭或 SSH 断连而退出——因为没设置会话脱离（session leader）和标准流重定向。真正可靠的后台运行必须靠配置文件 + systemd 或 supervisord，不推荐裸用命令行参数。
正确做法是修改 redis.conf：
- 把
daemonize no改成daemonize yes - 确保
pidfile路径可写（如/var/run/redis/redis-server.pid），且目录存在 - 设置
logfile（如/var/log/redis/redis-server.log），否则日志全丢到 stdout，后台后就看不到错误了 - 确认
dir指向的持久化目录（如/var/lib/redis）有读写权限
systemd 服务配置里 Type=simple 还是 Type=forking？
选 Type=forking。因为 Redis 在 daemonize yes 模式下会主动 fork 一次，主进程退出、子进程继续运行——这是典型的 forking 服务行为。用 simple 会导致 systemd 误判进程已死，反复拉起。
示例 /etc/systemd/system/redis-server.service 关键段：
[Service] Type=forking PIDFile=/var/run/redis/redis-server.pid ExecStart=/usr/bin/redis-server /etc/redis/redis.conf Restart=always User=redis Group=redis
注意：PIDFile 必须和 redis.conf 中的 pidfile 值严格一致，否则 systemctl status 查不到真实状态。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
密码认证启用后，redis-cli 连不上怎么办？
不是所有客户端都默认走认证，redis-cli 尤其容易漏掉 -a 或 AUTH 步骤。启用密码后，以下三点必须同步生效：
- 在
redis.conf中取消注释并设置requirepass your_password（不建议用空格或特殊字符） - 连接时显式传参：
redis-cli -a your_password；若提示Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe，说明系统启用了protected-mode yes且 bind 地址未放开，需一并检查 - 如果用
redis-cli进入交互模式，必须手动执行AUTH your_password，否则后续所有命令返回(error) NOAUTH Authentication required
另外：Redis 6+ 支持 ACL，requirepass 已属遗留方式，新部署建议用 ACL LOAD 配置用户，但兼容性要求高时仍以 requirepass 为准。
bind 127.0.0.1 导致远程连不上，但注释掉又报 FATAL CONFIG FILE ERROR
Redis 从 6.0 开始强制要求开启 protected-mode，当 bind 只留 127.0.0.1 且没设密码时，它会拒绝外部连接；但若你删掉 bind 行，Redis 启动会因缺少绑定地址直接报错。
安全又可用的解法是：
- 保留
bind 127.0.0.1 ::1（IPv4 + IPv6 回环） - 加上你要监听的内网 IP，例如
bind 127.0.0.1 192.168.1.100 ::1 - 确保
protected-mode yes（默认值），它会在无密码 + 非回环访问时自动拦截，正好兜底 - 不要设
bind 0.0.0.0，除非你明确做了防火墙限制（如 ufw/iptables 放行特定端口+源IP）
改完记得 systemctl daemon-reload && systemctl restart redis-server，并用 ss -tlnp | grep :6379 确认监听地址是否符合预期。
