冷启动会发生什么
实例重启后要先把 RDB 或 AOF 载入内存，这段时间进程处于 LOADING 状态，绝大多数命令被拒绝。加载完成后系统仍是冷的：分配器没有稳定的分配区，操作系统页缓存里没有数据文件，键空间刚建立，淘汰与过期逻辑也没有历史状态。此时若全量流量瞬间涌回，加载与请求争抢同一批 CPU 与内存带宽，恢复时间被拉长，内存占用还会出现叠加峰值。
基本信息
| 冷态特征 | 页缓存为空、分配器初态、键空间刚建立 |
|---|---|
| 加载阶段 | 进程处于 LOADING 状态，大部分命令被拒绝 |
| 恢复策略 | 阶梯放量，先小流量验证再逐步放开 |
| 健康检查 | liveness 与 readiness 分开，加载完成前不放行 |
| 观察字段 | INFO persistence 的 loading 与 rdb_* 系列 |
典型使用场景
- 计划内重启：先压低流量，确认实例进入稳定态再放开
- 主从切换：新主升维后同样经历冷态，切换后的流量要收敛
- 大实例恢复：数据量大、加载时间长，恢复窗口需要单独设计
- 容器编排：readiness 探针决定实例何时进入服务列表
- 回滚验证：对比恢复耗时与错误率，确认恢复流程真的有效
恢复过程观察
恢复过程观察
redis-cli INFO persistence | grep -E 'loading|rdb_last_bgsave_status' # 是否仍在加载
redis-cli INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio' # 建立冷态基线
redis-cli DBSIZE # 键空间是否已就位
redis-cli --latency-history -i 5 # 延迟是否已稳定，决定放量节奏
redis-cli INFO clients | grep connected_clients # 连接回涨速度是否符合节奏恢复阶段对照
| 阶段 | 状态 | 处置 |
|---|---|---|
| 加载中 | loading 为 1，命令被拒 | 持续拦流量，readiness 不通过 |
| 刚加载完 | 键空间就位但缓存冷 | 小流量试探，观察延迟与错误率 |
| 阶梯放量 | 流量按比例上升 | 每档确认指标稳定再上一档 |
| 全量恢复 | 指标回到常态区间 | 归档过程数据供复盘 |
加载阶段内存是叠加的：解析出的键空间加上读写缓冲。容器内存上限若按常态设置，加载峰值可能直接触发 OOM 被杀，陷入反复重启，上限要按加载峰值留余量。
健康检查只做端口连通性时，实例还在加载就被判定为健康并放进服务列表，业务会收到成片的 LOADING 类错误；readiness 必须能识别加载状态。