我平时接到最多的一个问题就是：“用Docker装Redis到底怎么装？”每次我都得从头讲一遍端口映射、数据卷、配置挂载这些东西，聊完对方还经常一脸懵。今天趁着整理笔记的功夫，我把Docker部署Redis这件事从设计思路到踩坑实录完整写下来，给需要的朋友一个能直接对照操作的手册。
先说清楚这篇到底覆盖什么：你会掌握Redis容器从镜像选型、参数设计、数据持久化到安全配置的完整链路，包括几个99%的人都会遇到的经典问题，比如容器外连不上、一重启就丢数据、配置文件改了不生效。适合刚接触Docker的开发者、负责部署的运维同学，以及所有被“容器化Redis”折磨过的人。
1. 先想清楚再动手：Docker部署Redis的整体设计思路
1.1 为什么用Docker跑Redis，而不是直接裸机安装
我知道有人会觉得，Redis这么轻量，干嘛非得套一层容器？直接apt install redis-server不就行了？我早期也这么干过，但后来在几台机器之间迁移配置、升级版本、复现环境时，裸机安装的痛点就出来了：不同系统的Redis包版本不一样，配置目录散落各处，卸载也不干净，换台机器等于重新走一遍流程。
Docker装Redis最核心的价值不是省资源，而是环境一致性。你在本地用redis:7.2-alpine跑起来的实例，和线上容器跑的镜像完全一致，Redis版本、编译参数、默认配置全部锁定，不会再出现“本地好好的，上线就出幺蛾子”的尴尬。另外迁移也舒服，docker run命令丢给新机器就能拉起同样环境，数据盘一挂，服务就搬家了。
但也有一个事实必须接受：容器里的Redis和宿主机是隔离的，网络、文件系统、时间都有独立一层。这层隔离既是好处，也是很多坑的来源，后面第3、4章我会逐个展开。
1.2 镜像选型：到底该选哪个tag
打开Docker Hub搜redis，能看到一堆tag，最常碰到的有这几个：
| 镜像tag | 说明 | 适合场景 |
|---|---|---|
redis:latest | 当前最新稳定版，但会随上游更新“漂移” | 本地测试、懒得管版本的场景 |
redis:7.2 | 锁大版本，小版本会更新 | 大多数生产环境，兼顾稳定和更新 |
redis:7.2-alpine | Alpine Linux精简版，体积小 | 资源敏感、镜像体积有要求的部署 |
redis:7.2-bookworm | Debian系，glibc完整 | 需要编译扩展、依赖系统库的场景 |
redis/redis-stack | 自带RediSearch、RedisJSON等模块 | 需要高级数据结构或全文检索 |
我给大多数项目的建议是选redis:7.2-alpine。Alpine镜像压缩后不到10MB，运行时内存占用也比Debian系低，在服务器上拉取快、占磁盘小。代价是Alpine用的musl libc，个别第三方扩展可能不兼容，但纯Redis场景完全够用。
从另一个角度看，选latest是风险最高的做法，半年后你重新部署，拉到的Redis可能已经跨了大版本，配置文件和行为都可能变。生产环境请务必锁版本，redis:7.2是底线，更稳妥的是直接锁到小版本redis:7.2.4（示例版本，按需替换）。
1.3 目录规划与文件准备
动手执行命令前，我习惯先在宿主机上把目录和配置文件准备好。否则后面挂载卷时手忙脚乱，还会出现在容器里找不到配置的窘境。
规划如下：
/opt/redis/ ├── data/ # Redis持久化数据存放目录 └── redis.conf # 自定义配置文件这套路径不是强制的，但建议所有Redis相关文件收拢到一个根目录，备份、升级、清理都方便。创建目录并准备配置文件时，用以下命令：
mkdir -p /opt/redis/data touch /opt/redis/redis.conf为什么先建目录？因为Docker的-v参数如果挂载一个宿主机不存在的目录，Docker会用它自己的权限帮你创建一个，而且属主经常是root，后面Redis写不进去，问题很难排查。手动先建好目录并规划权限，能省掉一大半权限相关的坑。
另外补充一句，不要在宿主机上凭空手写整个redis.conf，最好从官方默认配置改。取默认配置的方法在第3章我会给出命令，你也可以用容器临时跑一下再docker cp把配置掏出来，这个思路后面也会提到。
2. 核心细节拆解：端口、持久化、配置分离一个不能少
2.1 端口映射与网络模式
先祭出最基础的一行安装命令，大多数人第一次接触的就是这个：
docker run -d --name redis -p 6379:6379 redis:7.2-alpine-p 6379:6379把宿主机的6379端口映射到容器的6379端口。左侧是宿主机端口，右侧是容器端口。宿主机端口如果换成6380，那么外部访问就是你服务器的6380端口。需要说明的是，Redis默认端口6379，如果这台服务器只跑一个Redis实例，保持默认就行。但你要是想在同一台服务器上跑多个Redis，就得像下面这样：
docker run -d --name redis-6380 -p 6380:6379 redis:7.2-alpine docker run -d --name redis-6381 -p 6381:6379 redis:7.2-alpine这里有个关键点：每个容器要有独立的--name，宿主机端口不能冲突。我见过有人想省事共用端口，结果第二个容器直接启动失败，报port is already allocated，这个错误信息就是在告诉你端口被占用了。
网络模式简单提一句，如果你用--network host让容器直接共享宿主机网络，就不需要-p做端口映射了，Redis直接监听宿主机的6379。这种方式性能损耗更小，但隔离性也变差，且宿主机的6379被占用时容器无法启动。大多数场景我还是推荐默认的bridge网络加端口映射，够用且安全。
2.2 数据持久化：两种玩法必须分清
这是Redis容器化最大的坑。很多新手跑了两天Redis，容器一删，数据全没了，就是没做持久化。
Redis持久化有两种方式：RDB快照和AOF日志。官方镜像里RDB快照默认是开启的，但快照写入的位置在容器内的/data目录。如果你没挂载数据卷，这个/data目录跟着容器走，容器删除后数据就蒸发了。所以持久化的关键不是Redis配不配，而是你有没有把/data挂到宿主机上。
第一种玩法：挂数据卷的方式
docker run -d --name redis \ -v redis-data:/data \ redis:7.2-alpine这里redis-data是Docker管理的命名卷，数据实际存储位置在/var/lib/docker/volumes/redis-data/_data。好处是不用操心宿主机路径权限，方便得很。
第二种玩法：绑定挂载宿主机目录
docker run -d --name redis \ -v /opt/redis/data:/data \ redis:7.2-alpine绑定挂载的路径是固定的，你随时能在宿主机上看到rdb文件和aof文件，备份、拷贝都很直观。我个人更偏爱绑定挂载，因为可视、可控。
说明一下，AOF默认在官方镜像里是关闭的（只有RDB），如果你要开AOF，得在配置里加appendonly yes，这个配置同样通过第2.3节介绍的方式传入。
2.3 配置文件挂载的完整闭环
如果你只有比较简单的需求，比如设个密码、开个AOF，完全可以用命令行参数传入，比如：
docker run -d --name redis \ -p 6379:6379 \ -v /opt/redis/data:/data \ redis:7.2-alpine \ redis-server --requirepass mypassword --appendonly yes注意到没有，镜像名后面跟的redis-server --requirepass ...是容器启动时覆盖默认命令的新命令。官方镜像的默认启动命令是redis-server，你可以在后面追加启动参数，优先级高于配置文件。
但当配置项多起来后，命令行参数会变得乱七八糟，不好维护。正确做法是准备一份完整的redis.conf，挂载进容器：
docker run -d --name redis \ -p 6379:6379 \ -v /opt/redis/data:/data \ -v /opt/redis/redis.conf:/etc/redis/redis.conf \ redis:7.2-alpine \ redis-server /etc/redis/redis.conf这条命令包含一个必须深记的知识点：配置文件挂载后不会自动生效，必须显式把它作为参数传给redis-server，否则Redis会忽略掉这份配置文件，用默认配置启动。
潜在问题：如果宿主机上的redis.conf是空的（比如你刚touch出来），那么容器会用内置配置加上默认值启动，这时候你挂载一个空文件相当于什么都没配。所以，建议从一个最小可用配置起步，或者先取一份默认配置再改，下面这份是通用的最小可用配置：
bind 0.0.0.0 protected-mode no appendonly yes appendfilename "appendonly.aof" dir /data这里我特意加了bind 0.0.0.0和protected-mode no，因为在容器里，Redis默认bind的是127.0.0.1，如果你不设置，容器外（包括宿主机）是不可能通过这个端口连上Redis的。第4章会再复盘这个坑，这里先记住。
2.4 密码保护与安全基线
Redis默认没有密码，容器直接映射到宿主机端口后，等于把一台裸奔的数据库敞开在网络上，这在生产环境属于高危配置。网上被人拿来挖矿的Redis，绝大多数都是这种裸奔实例。
在配置里加密码非常简单：
requirepass 你的复杂密码于是启动命令加上配置挂载自然就带上了密码。验证时用：
redis-cli -h 127.0.0.1 -p 6379 -a 你的复杂密码另一个安全基线是：不要把Redis端口直接暴露到公网。如果你只是为了本机服务，甚至可以不加-p 6379:6379，改成让容器间通过Docker内部网络互通。如果确实需要外部访问，建议用防火墙规则只放行指定IP，或者用SSH隧道转发，这方面网上资料很多，我不展开。
另一个容易忽略的点：protected-mode是Redis的一个自我保护机制，默认情况下它只允许本机连接。当你设了密码，它还允许非本机连接，但如果你不设密码又不关保护模式，非本机连接一律拒绝。所以密码和protected-mode这两项要一起规划好，不要只配密码但忘了protected-mode，或者反过来。
3. 完整实操记录：从拉取镜像到验证读写
前两章把原理说透了，这一章给一套可直接复制的完整流程。我们按生产环境的规格来走，包含持久化、密码、配置分离、资源限制和自动重启。
3.1 环境检查
先确认服务器上已经装好Docker：
docker --version如果输出形如Docker version 24.0.x，说明没问题。再检查一下端口占用情况，确认6379没被宿主机其他进程占用：
ss -lntp | grep 6379没有输出则说明端口空闲。如果机器上已经跑了一个Redis服务，要么先停掉，要么把Docker映射到6380端口，避免冲突。
3.2 拉取镜像与参数解析
锁定版本并拉取镜像：
docker pull redis:7.2-alpine这里我指定了7.2-alpine而不是latest，道理前面讲过——生产环境要的是可重复性。
拉取完成后查看镜像：
docker images | grep redis如果看到redis 7.2-alpine那一行就绪即可。在写启动命令之前，我先整理一下需要哪些参数，方便你理解每个flag的作用：
| 参数 | 作用 | 我的说明 |
|---|---|---|
-d | 后台运行容器 | 不加这个会一直卡在前台，日志刷屏 |
--name redis | 给容器命名 | 后续管理、查看日志都用这个名称 |
-p 6379:6379 | 端口映射 | 外部流量从宿主机6379进入容器6379 |
-v /opt/redis/data:/data | 持久化数据目录 | 容器删除后数据不丢 |
-v /opt/redis/redis.conf:/etc/redis/redis.conf | 配置文件挂载 | 注意后面的启动参数要引用它 |
--restart always | 重启策略 | 服务器重启或容器崩溃后自动拉起 |
-m 512m | 内存限制 | 防止Redis占满宿主机内存 |
--cpus 1 | CPU限制 | 限制容器最多用1个核 |
3.3 启动容器并验证
现在正式执行启动命令：
docker run -d \ --name redis \ -p 6379:6379 \ -v /opt/redis/data:/data \ -v /opt/redis/redis.conf:/etc/redis/redis.conf \ --restart always \ -m 512m \ --cpus 1 \ redis:7.2-alpine \ redis-server /etc/redis/redis.conf如果你现在直接跑，多半会碰到一个报错：chown: changing ownership of '/data': Permission denied，这是因为挂载目录权限问题，我在第4章的4.3节会专门讲。为了一鼓作气跑通，这里先提前处理：
chown 999:999 /opt/redis/dataRedis容器里的redis用户UID是999，把宿主机的data目录属主改成999，让容器里有权限写入RDB和AOF文件。
启动后，连续执行两条验证命令：
docker ps | grep redis docker logs redisdocker ps看到容器状态是Up就说明进程常驻了，docker logs里如果能看到类似Ready to accept connections的日志，一行行的开始，说明Redis已经就绪。
3.4 连通性与读写验证
先确认容器自身的Redis能响应，进入容器执行命令：
docker exec -it redis redis-cli -a 你的复杂密码 ping返回PONG就说明容器内Redis正常。但这一步不能证明宿主机能连通，因为还有端口映射和防火墙这两道关。测试宿主机到容器的连通性：
redis-cli -h 127.0.0.1 -p 6379 -a 你的复杂密码 ping如果宿主机没有装redis-cli，可以用docker exec代替，或者直接跑：
curl -v telnet://127.0.0.1:6379看到-ERR operation not permitted之类的响应就说明端口已经通到了，只是需要认证。接着做一次简单的写入验证：
redis-cli -h 127.0.0.1 -p 6379 -a 你的复杂密码 set test_key "hello-docker" redis-cli -h 127.0.0.1 -p 6379 -a 你的复杂密码 get test_key能正常写入并读回hello-docker，这一套部署基本成功。
接着验证持久化。写入数据后，重启容器并再次读取：
docker restart redis redis-cli -h 127.0.0.1 -p 6379 -a 你的复杂密码 get test_key如果在容器重启后数据依然存在，说明持久化配置生效了。这也是每次部署Redis后我必做的一项验收动作，数据不丢才是持久化的初衷。
3.5 从官方镜像获取默认配置再改
刚才的第3.3节我假设你已经准备好了一份redis.conf。如果没有，这里提供一个最正规的获取方式：先从镜像里掏一份官方默认配置出来。
# 先临时启动一个容器 docker run -d --name redis-tmp redis:7.2-alpine # 从容器里拷贝默认配置到宿主机 docker cp redis-tmp:/etc/redis/redis.conf /opt/redis/redis.conf # 删掉临时容器 docker rm -f redis-tmp拿到的default配置文件非常完整，里面每一行都有注释说明。在此基础上改配置，比从零手写可靠得多。改完后建议用以下命令在容器内验证配置语法：
docker run --rm -v /opt/redis/redis.conf:/etc/redis/redis.conf redis:7.2-alpine redis-server /etc/redis/redis.conf --test-memory 0严格说--test-memory 0不会校验配置语法，更常用的做法是直接用redis-server /etc/redis/redis.conf前台试跑几秒，如果配置有问题会立刻报错退出。试跑没问题再正式启动。
4. 常见问题与排查实录（含避坑技巧）
4.1 容器外连不上Redis的两个经典原因
这是被问得最多的问题：“明明容器起来了，redis-cli连的时候却报Connection refused或者一直超时”。我把排查路径整理成一张速查表：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
Connection refused | 容器只bind了127.0.0.1 | 在配置里加bind 0.0.0.0 |
Connection refused | 端口映射没做或映射错方向 | 检查docker ps的PORTS列，确认0.0.0.0:6379->6379/tcp |
Connection timed out | 防火墙拦截 | 检查云安全组、宿主机iptables，放行6379 |
NOAUTH Authentication required | 设置了密码但没带-a | 用redis-cli -a 密码重连 |
DENIED Redis is running in protected mode | protected-mode开启且未设置密码 | 关闭protected-mode或设置requirepass |
排查顺序建议是：先看docker ps确认端口映射正常，再看docker logs redis确认bind地址，最后查防火墙。每一步都能通过现象倒推，不要上来就怀疑网络。
另外分享一个我自己特别常用的小技巧：用docker exec进容器里跑redis-cli ping，如果容器内正常、容器外不通，那问题肯定出在端口映射或者防火墙；如果容器内也不通，那就得检查Redis进程本身和bind配置。这一步能快速把问题“拦腰截断”。
4.2 写配置文件后Redis无法启动
修改了redis.conf后重启容器，结果容器一直重启循环，日志刷出一堆报错。最常见的两类：一是配置文件里有不存在的指令，比如把requirepass拼错了；二是配置项值不合法，比如maxmemory 512mb写成了512MB。
解决思路并不复杂：先用前台模式启动容器试一下，报错会直接打在命令行里：
docker run --rm -v /opt/redis/redis.conf:/etc/redis/redis.conf redis:7.2-alpine redis-server /etc/redis/redis.conf如果配置有问题，Redis会输出Bad directive或者Invalid argument一类的提示，照着改就行。这比反复docker restart再docker logs来回刷要高效得多，我每次改完配置都用这个命令验证后再正式启动。
顺带提一个让人迷惑的情况：有时改动配置文件后，docker restart容器，但新配置没有生效。原因往往是容器启动命令里没带配置文件路径，Redis还在用内置默认配置，你挂载的那份conf根本没人读。记住启动命令末尾一定要有redis-server /etc/redis/redis.conf，缺了这步一切白配。
4.3 数据目录权限导致启动失败
字典型的报错：
chown: changing ownership of '/data': Permission denied原因在前面第3.3节已经提前处理过：官方alpine镜像里的Redis以uid 999运行，而宿主机上挂载的目录默认属主可能是root，容器内的Redis用户没有权限写RDB和AOF文件，启动时就会失败。
解决办法一句话：在宿主机上把数据目录的属主改成999。
chown 999:999 /opt/redis/data但要注意两点：一是这个命令只对绑定挂载的目录有用，命名卷的话直接在宿主机上找到对应目录再执行同样操作；二是如果redis.conf里的dir指向了别的路径，比如/tmp，那你挂载的数据目录就不会被写入，数据持久化等于没做。所以配置里的dir /data要和挂载点保持一致，这是我的经验之谈，至少见过三次因为dir指错路径导致“持久化失效”的案例。
4.4 一重启就丢数据
这种情况多数不是Redis没持久化，而是容器重启后数据存在旧容器里，新容器没挂载同一份数据卷。比如你执行了：
docker rm redis docker run -d --name redis redis:7.2-alpine如果不带-v，新容器就是一片干净的数据目录，旧数据当然全没了。所以删除容器前，务必确认启动命令里包含数据卷的挂载。还有人把-v /opt/redis/data:/data写成了-v /opt/redis/data:/var/lib/redis，Redis启动时找/data找不到，持久化配置自然失效。
鉴别的办法很简单：用docker inspect查看容器的Mounts信息：
docker inspect redis | grep -A5 Mounts看到Source: /opt/redis/data对应Destination: /data，才是正确配置。一旦发现Destination不对，赶紧修改启动方式重新创建容器。
4.5 日志与调试的小技巧
容器化Redis的日志默认输出到stdout，通过docker logs redis就能查看。但有时候你想把日志配置成文件级别，在配置里加了logfile "/var/log/redis/redis.log"，然后发现docker logs里反而没有日志了。因为日志写了文件，而容器没有挂载/var/log/redis目录，文件落在容器可写层，容器一删日志就没了。
这不算错误，但容易让人困惑。我的做法是：除非有特殊需求（比如对接日志采集），否则不要改logfile配置，让日志走stdout，用docker logs统一查看，这才是容器日志的正确打开方式。
另外，Alpine镜像里默认没有bash、没有vim、没有gdb，只有最精简的sh和常用工具。进容器排查时别指望有完整调试环境，正确的姿势是在宿主机上装一个redis-cli或者用docker exec调容器内的redis-cli，配置文件直接在宿主机改完再挂载进去，改完重新启动容器即可。
4.6 时区不一致的问题
容器默认时区是UTC，宿主机如果是东八区，两边时间对不上，日志时间戳和宿主机相差8小时，排查问题时会很别扭。
处理方式是在启动时挂载时区文件：
-v /etc/localtime:/etc/localtime:ro或者通过环境变量方式处理，当然更干净的做法是用TZ环境变量：
-e TZ=Asia/Shanghai不过Alpine基础镜像里的时区数据可能不全，稳妥的做法还是挂载宿主机的/etc/localtime。挂载后进容器执行date，就能看到和宿主机一致的时间，日志时间戳也顺眼了。
5. 生产化操作：容器管理、备份恢复与扩容注意事项
5.1 常见的管理命令
部署完成，接下来就是日常管理。我把高频命令整理成一份可直接使用的速查表：
# 查看运行状态 docker ps -a | grep redis # 查看日志 docker logs -f redis # 进入容器命令行 docker exec -it redis sh # 重启容器 docker restart redis # 停止容器 docker stop redis # 删除容器（数据卷不删则数据还在） docker rm redis每次执行docker stop之后再做docker start，因为容器有--restart always策略，有些场景下stop会被自动拉起打断，这时候可以临时用docker update --restart=no redis再停。这个细节我在生产环境踩过一次：明明docker stop了，过几秒容器又起来了，排查了半天才发现是重启策略在作怪。
5.2 数据备份与恢复
Redis的RDB快照文件就是一个文件，备份起来非常直接：
# 在宿主机上打tar包 tar czf redis-data-$(date +%F).tar.gz -C /opt/redis/data .恢复时，新服务器上按同样路径解压，再启动容器就行。AOF文件同样在挂载目录下，不需要单独处理。
比较进阶的备份方式是使用SAVE或BGSAVE命令触发快照后拷贝文件。如果Redis里存的是缓存数据，丢了也不心疼，那RDB备份就够用；如果Redis存了有状态的数据，比如任务队列的进度，建议AOF和RDB同时开启，备份时两个文件都留一份。
我在实际运维里还发现一个备份盲区：很多人只备份了容器的可写层（比如用docker commit），却忽略了数据卷。docker commit只能打包容器文件系统的可写层，不包括数据卷里的RDB和AOF，所以即使提交了镜像，数据也不会在里面。备份数据一定要备份挂载目录或命名卷的内容，这是两套完全不同的东西。
5.3 资源限制与监控
Redis是内存数据库，内存管理必须前置。容器层面做限制只是兜底，真正要关注的是Redis内部的maxmemory配置。如果maxmemory不设，Redis在内存压力下可能把操作系统内存耗尽，触发OOM Killer，到时候连宿主机都会受影响。
建议在redis.conf里配置：
maxmemory 400mb maxmemory-policy allkeys-lru这里的400mb给容器内Redis进程留了余量，因为容器又被docker run的-m 512m限制住，两层约束形成防御纵深。maxmemory-policy allkeys-lru表示内存满了之后按LRU淘汰键，这是缓存型Redis最常用的策略。
监控方面，最简单的方式是用docker stats看容器实时资源占用：
docker stats redis也可以通过redis-cli --stat持续查看Redis内部的键数量、命令处理数、内存使用量：
docker exec redis redis-cli -a 你的复杂密码 --stat把这个输出接到告警系统里，基本能覆盖Redis的可观测性需求。内存增长曲线异常时，通常意味着某条业务线在向Redis里塞无限增长的数据，这时候配合key扫描和TTL审查就能定位问题。
6. 安全加固和网络策略
讲完常规部署和管理，必须把安全这块单独拉出来聊一聊。Redis本身自带的功能很纯粹，但正因为它纯粹，常被忽略的安全项目反而多。
6.1 不要让Redis裸奔在公网
如果你的Redis只是给本机或内网服务使用，最安全的操作是根本不映射端口。Docker容器之间通过自定义网络访问Redis时不走宿主机端口，直接走容器网络。比如你有一个后端服务容器，和Redis容器在同一条Docker network下，服务里配置的Redis地址应该是redis:6379，而不是宿主机的127.0.0.1:6379。
# 创建一个自定义网络 docker network create app-net # Redis容器加入网络 docker run -d --name redis --network app-net redis:7.2-alpine # 业务容器加入网络，两者互通 docker run -d --name app --network app-net your-app-image这种方式下，Redis不会暴露到宿主机网卡，只有同网络内的容器能访问，安全性大幅提升。代价是外部工具连不进来，调试稍麻烦，但用docker exec也能解决。
6.2 密码之外的额外防线
Redis 6以后的默认配置里，protected-mode yes意味着即使没有密码，也拒绝非本机访问。但很多人在容器化部署时主动设置了protected-mode no（包括我自己的配置文件里也有），这时如果忘了设密码，Redis就完全敞开。
所以我的底线组合是：
- 设置足够强度的
requirepass； - 保持
protected-mode yes； - 不映射公网或通过防火墙只放行可信IP；
- 如果Redis仅内网服务使用，优先用Docker内部网络。
这四条做到位，Redis容器才算有基本防护。别等到被入侵者植入挖矿进程才想起来补，那已经晚了。
6.3 基础镜像的安全更新
最后一个安全话题：镜像更新。redis:7.2-alpine这类镜像会定期推送安全更新，但前提是你主动docker pull并且重建容器。生产环境里镜像几个月不更新是常态，一旦上游修复了某个高危漏洞，你跑的还是旧版本，风险就会一直悬在头上。
我的建议是设定一个镜像更新周期，比如每月执行一次：
docker pull redis:7.2-alpine docker stop redis docker rename redis redis-old docker run -d --name redis ...（省略重复参数） docker rm redis-old只要启动命令里挂载的数据卷和配置文件路径不变，容器重建不会丢数据。这套“拉镜像、重建容器、清理旧容器”的流程，也是镜像更新的标准操作方式。
7. 写在最后：根据个人经验的几点体会
前前后后整理了一长串，最后分享几个我觉得真正有用的实操体会。
第一个是命令别靠记忆，靠脚本。Docker部署Redis不难，但是参数多，光是一个docker run就能写二三十行。手动敲很容易漏参数或写错路径。我现在为每个Redis实例都准备一份部署脚本，脚本里固定写好端口、目录、资源限制、重启策略，换机器部署改改路径就能用，可重复性远胜每次手打。
第二个是关于排错的心态。容器化Redis出问题时，先跳出容器思维，回到最基础的事实：Redis进程到底跑没跑、端口到底通没通、数据到底写没写进去。用docker exec和docker logs拿到第一手信息再做判断，大部分坑很快就能定位，慌是没用的。
第三个是始终给“重建”留后路。容器的优势就在于可以随时销毁重建，数据在数据卷、配置在挂载文件里、启动参数在部署脚本里，三者齐备，整个Redis就可以在任意一台机器上快速重建。如果你发现自己必须“进容器里改文件才能工作”，那说明部署设计出了问题，赶紧把配置分离出来。
Docker部署Redis的学习曲线不算陡，但坑的数量不少。希望这篇笔记能让你少踩几个我踩过的雷。趁着手感热，去看看你自己机器上的Redis，把数据卷挂载检查一遍，密码补上，重启策略配上，能顺手做掉的安全加固做掉。用不了十分钟，但后面省下的可能是一整晚和一堆头发。
