凌晨两点。一通报警

问题拆解这方面，为什么“开了持久化还会丢数据”？

场景很简单——我们要保证服务重启后 Session 能继续存在。运维给实例配置的是：

• {@literal RDB} 配置为 {@literal save }；{@literal appendonly yes};{@literal appendfsync everysec}}
• {@literal docker stop} 用于滚动重启；{@literal SIGTERM}->{@literal SIGKILL}->AOF尾部截断}}

1. {容器运行两小时；最近一次 RDB 保存是30分钟前}
2. {线上触发滚动重启；使用 {@literal docker stop} 优雅退出}
3. {重新启动后检查过去30分钟内近二万条 Session，其中一万多条消失}
由于 **RDB 与 AOF 的组合并没有覆盖“短时间内大量写入并立即重启”的极端情况**。RDB 在后台异步执行，当主进程收到 {@literal SIGTERM} 时它等待子进程完成。但 Docker 默认只有10秒 grace period。怎么说呢，如果生成 RDB 文件花费超过10秒。 它就被强制杀掉，从而得到一个空或损坏的快照。AOF 在每秒 fsync，但当磁盘 I/O 边缘时一样可能因为超时而被截断。于是启动时 Redis 把尾部命令抛弃或跳过修复，而这些未刷到磁盘的数据就彻底消亡。常规手工测试「SET + 重启」根本无法再现这种瞬时高压 + 突然停机的竞争，所以必须引入可重复、覆盖真实故障模式的自动检测。---

方案设计的观点是，Pytest + Docker 参数化验证持久性一致性

至于目标分三部分，

• {快速创建一个预设 Persistence 策略的 Redis 容器}
• {模拟真实压力下的大量写操作}
• {用不同方式杀掉容器。再重新拉起检查一致性}
**技术选型**： * **Pytest** —— 参数生成强大，可轻松构造几十种不同 Persistence 配置。* **testcontainers‑python** —— 自动处理容器生命周期。无脏环境，可直接嵌到 CI。* **Docker Compose** 不够灵活，因为需要为每一种配置信息手写 YAML；而通过代码动态挂载自定义 `redis.conf` 更省事。整体架构这方面，text conftest.py ──┬─ fixture : 创建根据传参生成自定义 redis.conf 并挂载到容器；话说回来，│ └─ 启动 & 停止由 TestContainers 管理；tests/ ├─ test_graceful_stop.py ：模拟 docker stop 情况；└─ test_kill.py ：模拟 docker kill 情况；---

说到主要实现，一步步搭出自动化验证套件

第一步先 — 定义可按需配置 Redis 的容器 Fixture