📚 课程目录第4章 Redis实例生命周期自动化

4. Redis实例生命周期自动化

Redis实例的生命周期管理，是自动化运维中最基础也最容易出问题的一环。手工执行 redis-server、redis-cli shutdown 看似简单，但当实例数量从几个增长到几十上百个，且分布在多台宿主机上时，缺乏统一脚本和幂等约束的操作会迅速演变为事故来源：重复启动导致端口冲突、误停生产实例、销毁时残留数据目录和配置文件、重启后配置漂移等。本节围绕“创建、启动、停止、重启、销毁”五个动作，讨论如何用脚本把它们封装成可重复执行、结果可预期的自动化操作。

一、生命周期动作的语义与幂等目标

幂等的核心含义是：同一个操作执行一次和执行多次，对系统最终状态的影响相同。对Redis实例而言，每个动作都应先判断“目标状态是否已达成”，再决定是否真正执行变更。下面这张图给出了五个动作的状态判断与幂等处理逻辑，是本节脚本设计的骨架。

二、实例元数据：脚本的单一事实来源

要让脚本幂等，首先需要一个稳定的“实例描述”。推荐为每个实例维护一份元数据，字段至少包括：实例名、端口、数据目录、配置文件路径、日志路径、pidfile路径、最大内存、持久化策略。这份元数据可以由一个统一的 instances.conf 或环境变量文件承载，脚本所有动作都从它读取，而不是在命令行里临时拼参数。这样做的价值在于：创建时按它生成配置，启动时按它定位文件，停止时按它找到pidfile，销毁时按它清理目录，五个动作共享同一份事实来源，避免“创建用A路径、停止找B路径”的错位。

# instances.conf 示例（每行一个实例，冒号分隔）
# name:port:dir:maxmemory:policy
order-cache:7001:/data/redis/order-cache:2gb:allkeys-lru
session-store:7002:/data/redis/session-store:1gb:volatile-lru
rank-board:7003:/data/redis/rank-board:512mb:noeviction

三、创建与启动：先判断，再变更

创建动作的幂等判断点是“目录与配置文件是否已存在且内容一致”。如果目录不存在，则创建目录、生成 redis.conf、写入基础参数；如果目录已存在，则读取现有配置并与期望配置比对，一致则跳过，不一致则输出差异并告警，而不是盲目覆盖——盲目覆盖可能抹掉人工调整过的参数，也可能在实例运行中造成配置与内存状态不一致。

启动动作的判断点是“实例是否已经在响应”。最可靠的方式不是看进程名，而是用 redis-cli -p PORT PING 探测。返回 PONG 说明实例已就绪，直接跳过；连接被拒绝或超时，才真正执行启动。启动后不能立即返回成功，而要轮询PING，直到就绪或达到超时阈值（例如30秒）。下面是一段可参考的启动逻辑：

start_instance() {
  local name=$1 port=$2 dir=$3
  if redis-cli -p "$port" PING 2>/dev/null | grep -q PONG; then
    echo "[$name] already running on port $port, skip."
    return 0
  fi
  redis-server "$dir/redis.conf" --daemonize yes
  for i in $(seq 1 30); do
    if redis-cli -p "$port" PING 2>/dev/null | grep -q PONG; then
      echo "[$name] started, ready in ${i}s."
      return 0
    fi
    sleep 1
  done
  echo "[$name] start timeout after 30s." >&2
  return 1
}

这段逻辑重复执行多次，结果都是“实例处于运行状态”，符合幂等要求。注意 --daemonize yes 让Redis转入后台，脚本通过PING确认就绪，而不是依赖进程返回值。

四、停止与重启：优雅优先，超时兜底

停止动作先判断进程是否存在。若pidfile不存在且端口无响应，说明实例已停止，直接返回成功——这正是幂等的体现：对已停止的实例再次执行停止，不应报错。若实例在运行，优先使用 redis-cli -p PORT SHUTDOWN SAVE，让Redis在关闭前完成RDB落盘，避免数据丢失。发送关闭命令后等待进程退出，若超过阈值（例如15秒）仍未退出，再用 kill -TERM，最后才考虑 kill -9。每一步都要记录，便于事后排查为何走了强制路径。

重启是“幂等停止 + 幂等启动”的组合，但要注意顺序和校验：停止必须确认旧进程完全退出、端口释放后，才能启动新进程，否则会出现端口占用导致启动失败。重启完成后，除了PING，还应校验关键指标，例如 DBSIZE 与重启前记录的值对比，确认数据已从RDB正确加载。若DBSIZE异常偏小，说明持久化或加载环节可能有问题，应告警而非静默通过。

五、销毁：不可逆动作的防护设计

销毁是五个动作中唯一不可逆的，必须单独设计防护。建议流程为：先执行幂等停止，确认无进程占用目录；然后将RDB文件备份到归档目录（例如按 实例名_日期 命名）；再删除实例目录、配置、日志和pidfile；最后从实例清单中移除该实例记录。为防止误操作，脚本应要求显式传入 --confirm 参数，或要求输入实例名二次确认。销毁完成后，校验目录确实不存在、端口处于空闲状态，才算成功。

销毁动作不要与停止动作共用同一个“已停止即成功”的短路逻辑。停止对已停止实例返回成功是合理的，但销毁若发现目录不存在，应区分“从未创建”和“已被销毁”两种情况，前者可提示无需销毁，后者应确认清单记录是否已清理，避免清单与实际状态长期不一致。

六、把五个动作组织成统一入口

实际落地时，建议用一个入口脚本接收“动作 + 实例名”两个参数，内部根据动作分发到对应函数，并统一处理日志、退出码和错误信息。退出码约定为：0成功、1执行失败、2参数错误、3超时。这样上层调度系统（如Ansible、定时任务或发布流水线）可以依据退出码判断是否需要重试或告警。所有动作在执行前都打印“当前状态 → 目标状态 → 是否变更”，让每次执行的决策过程可追溯，这对排查“为什么这次没有真正启动”这类问题非常关键。

最后需要强调的是，幂等不等于“什么都不做”。幂等的目标是让重复执行安全，而不是让脚本变得迟钝。判断逻辑要准确：该跳过时跳过，该变更时变更，该失败时明确失败。把状态判断、变更执行、结果校验三段分开，每个动作都遵循这个结构，生命周期自动化才能真正稳定可靠。