systemd本身不提供跨节点高可用，但可通过强化服务单元、配合redis自身机制、添加健康检查及日志监控实现服务级高可靠守护。
Linux中systemd本身不提供跨节点高可用（如主从自动故障转移），但可通过合理配置+外部组件实现Redis服务级的高可靠守护：确保单机崩溃后自动拉起、异常退出时重启、资源不足时保护性干预，并为集群或哨兵架构打下基础。
一、systemd服务单元强化基础守护能力
默认redis-server.service往往只做简单启停。要提升健壮性，需在/etc/systemd/system/redis-server.service中补充关键参数：
- Restart=always：进程任何原因退出（包括OOM、信号终止、崩溃）都立即重启
- RestartSec=5：重启前等待5秒，避免高频闪退打满日志
- StartLimitIntervalSec=60 和 StartLimitBurst=3：1分钟内最多启动3次，超限则暂停并报错，防止配置错误导致无限循环
- MemoryLimit=2G（按实际调整）：硬限制内存使用，OOM前由内核oom_killer杀掉进程，触发Restart机制
- User=redis 和 Group=redis：禁止root运行，降低提权风险
- ProtectSystem=full 和 PrivateTmp=yes：隔离系统目录与临时文件，增强安全性
二、配合Redis自身机制规避单点失效
systemd管的是进程生命周期，而Redis的“可用”还需数据和服务逻辑保障。必须同步配置：
- 在/etc/redis/redis.conf中启用supervised systemd，让Redis主动向systemd汇报状态，而非仅靠pid文件
- 设置maxmemory和maxmemory-policy（如allkeys-lru），防止内存耗尽卡死
- 开启appendonly yes并配appendfsync everysec，保证宕机后AOF可恢复
- 若用哨兵模式，确保sentinel.conf也由独立systemd服务管理（如redis-sentinel.service），且依赖redis-server启动
三、添加健康检查钩子（可选但推荐）
单纯进程存活 ≠ 服务可用。可在service文件中加入简单的连通性验证：
- 定义ExecStartPost=/usr/bin/timeout 10 /usr/bin/redis-cli ping || /bin/kill $MAINPID：启动后10秒内ping不通就主动杀进程，触发Restart
- 或用HealthCheckIntervalSec=30（需systemd v249+）配合自定义脚本，定期探测INFO replication状态
四、日志与监控衔接
高可用离不开可观测性：
- 确保StandardOutput=journal和StandardError=journal开启，所有输出进journald
- 用journalctl -u redis-server -f实时跟踪；设MaxJournalSize=100M防日志撑爆磁盘
- 配合Prometheus + redis_exporter采集指标，当redis_up == 0持续超过2分钟，触发告警并人工介入
