Docker Compose用命名卷持久化Redis

Docker Compose持久化Redis需要两项配置配合：把命名卷挂到容器的/data，并让Redis把数据写入这个目录。命名卷保留文件，AOF或RDB负责把内存数据落盘。只创建卷、没有有效持久化文件，仍不能保证重建后找回最新数据。

下面在独立的本地演示项目中完成配置、查看卷、写入数据和重建检查。适用于已安装Docker Desktop及Compose插件的环境；图片是原创界面说明图，用于辨认操作位置，具体布局可能随Docker Desktop版本变化。

Compose官方地址：https://docs.docker.com/compose/

Redis官方镜像：https://hub.docker.com/_/redis

步骤1：保存Compose配置并启动示例项目

创建一个独立演示目录，在常用编辑器里选择“文件 → 新建文件”，粘贴下面的配置，使用“文件 → 另存为”保存为该目录下的compose.yaml。确认不是compose.yaml.txt。不同编辑器的菜单名称略有差异，保存的文件名和内容才是关键。

name: redis-volume-lab
services:
  redis:
    # 示例使用官方镜像固定补丁标签；正式部署还可固定镜像摘要。
    image: redis:7.4.12
    command: ["redis-server", "--appendonly", "yes", "--appendfsync", "everysec", "--dir", "/data"]
    volumes:
      # 左边是逻辑卷名，右边是容器内持久化目录。
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10
volumes:
  # 保持项目名不变时，默认实体卷名为redis-volume-lab_redis-data。
  redis-data: {}

服务层的volumes定义挂载，顶层的volumes声明卷，两处都要有。这里固定项目名redis-volume-lab，默认实体卷名由项目名和逻辑卷名组合。不设置ports，所有Redis命令都从容器内部执行；这是本地持久化演示，不是面向公网的部署方案。若已有同名项目，先换一组独立名称，避免连接到旧实验的数据。

在该目录的命令行运行以下命令。命令由读者在自己的演示环境执行，本文没有将示例输出当作实测记录。

# 在独立演示目录保存compose.yaml后执行；不会发布宿主机端口。
docker compose up -d --wait
# 确认服务状态；若失败先阅读该演示服务日志。
docker compose ps
docker compose logs --tail=50 redis

启动成功后进入Docker Desktop左侧Containers，找到redis-volume-lab项目并展开，观察redis服务处于运行状态。--wait结合这里的healthcheck等待服务就绪；若等待超时，先看日志和镜像拉取错误，不要反复删除卷。容器运行只是起点，接下来还要确认卷确实挂载。

步骤2：在Volumes中找到命名卷与数据

进入Docker Desktop左侧Volumes，在Search输入redis-volume-lab_redis-data，点击对应卷名。在详情的Container in-use标签查看挂载容器和Target，目标应为/data。这比仅凭容器名称推断数据位置更直接。

然后回到演示目录，写入一条专用数据并生成检查点。SAVE是同步操作，只用于这里的小数据演示；不要直接在大规模线上实例照搬。

# 只写入专用演示键，不给它设置过期时间。
docker compose exec -T redis redis-cli SET lab:volume:181 kept
# 明确生成一次快照，作为本次重建演示的已落盘检查点。
docker compose exec -T redis redis-cli SAVE
docker compose exec -T redis redis-cli GET lab:volume:181

SET与SAVE均应返回成功，GET应读到kept；任何一项报错都应先处理，不能继续声称数据已经保存。回到同一个卷的Stored data标签，可以浏览目录。AOF启用后通常能看到appendonlydir目录；这次SAVE还应生成dump.rdb。AOF在新版本中可能由多段文件和清单组成，不必寻找唯一的appendonly.aof文件，更不要在运行期间手工编辑这些文件。

本文显式生成快照是为了让演示有明确检查点。日常写入仍受AOF同步策略约束：everysec发生异常断电时可能丢失最近约一秒的数据，命名卷不会把异步写入变成零丢失承诺。

步骤3：重建容器后读取演示键

只在刚才的独立演示项目中执行下面的停止、移除与启动。普通down会移除容器及相关网络，默认保留命名卷。随后up再次使用同一实体卷，因此容器可以变化，保存的数据目录不必变化。

# 仅在本文独立演示项目内执行，停止并移除容器，保留命名卷。
docker compose down
# 使用同一份compose.yaml、同一项目名重新创建容器。
docker compose up -d --wait
docker compose exec -T redis redis-cli GET lab:volume:181
# 查看挂载对象；卷名应仍然与第一次相同。
docker volume inspect redis-volume-lab_redis-data

读取成功的判断是GET仍返回kept，同时volume inspect显示卷仍存在。进入Docker Desktop的Volumes → redis-volume-lab_redis-data → Container in-use，查看新建容器对/data的引用；不要要求重建前后容器ID一致。最终确认要同时看业务数据与卷挂载，单看“Running”不说明恢复成功。

常见问题与保留数据的操作边界

为什么重建后像全新Redis？先对照实际Docker context、项目名和卷名，再看挂载目标与Redis的dir配置。换目录后项目名变化、命令行使用不同-p参数，都会让你接入另一组资源。本文顶层name有助于保持项目稳定，但命令行项目名仍可能覆盖它。还要确认读写使用同一数据库编号，演示默认DB 0，并确认键没有设置TTL。

name固定的卷能跨项目共享吗？顶层卷的name可以指定不带项目作用域的实体名称，external则用于引用预先存在且由外部管理的卷。它们不是必须选项。本教程采用默认项目作用域以便隔离；不要把一个Redis数据卷同时挂给两个独立写入实例。

能直接把卷里的文件复制当备份吗？持久化和备份是两件事。命名卷主要保护容器生命周期变化时的数据，不能覆盖磁盘损坏、误删或宿主机丢失。正式环境还需要一致性备份、独立保存位置与恢复演练，不能用文件目录可见替代备份成功。

为什么不直接使用latest镜像？演示选用官方提供的固定补丁标签，减少重建时版本漂移。正式升级应单独做兼容性计划，保留备份；固定镜像也不意味着永不升级。本文的重建检查保持版本不变，避免把升级与持久化问题混在一起。

Docker Desktop卷管理参考：https://docs.docker.com/desktop/use-desktop/volumes/

Redis持久化参考：https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/