Docker部署Redis 5.0.12：配置、启动与常见问题排查

我不太确定别人是怎么部署 Redis 的，但就我自己这几年的实操体会来说，Docker 装 Redis 从来不是一个“docker run 一把梭”就能收工的事。Redis 5.0.12 这个版本在不少跑了几年的业务系统里依然占据主流，它既有 5.0 系列稳定性上的收敛，又没有 6.0、7.0 带来的一些兼容性迁移成本。这篇文章我会围绕 Docker + Redis 5.0.12 这条主线，从版本选型、环境检查、配置文件准备、容器启动到常见问题排查，把一套能直接抄作业的详细步骤完整过一遍，也会把我在实施过程中踩过的坑穿插在里面。无论你是第一次用 Docker 部署 Redis，还是以前裸机安装过 Redis 现在想迁到容器环境，这篇文章的思路和命令都能直接拿来用。

1. 为什么是 Redis 5.0.12 + Docker，而不是追求最新版

1.1 版本选型得看兼容性和稳定性，不只是追新

Redis 5.0 是一个典型的“承上启下”版本。它在 4.0 的基础上引入了 Stream 数据结构，把消息队列这类场景从 List、Pub/Sub 的诸多限制中解放出来，同时对外部模块的加载机制也做了重构。之后 6.0、7.0 虽然带来了客户端缓存、ACL 强化、多线程 IO 等新能力，但如果你手头的业务代码还在用旧版客户端库，或者运维体系里依赖着一套比较老的主从复制脚本，直接跨大版本升级很容易遇到 Redis 协议细节变化带来的兼容性问题。

5.0.12 是 5.0.x 这条分支上的最后一个修复版本。什么意思呢？就是 5.0 系列早期版本里那些内存泄漏、主从切换异常、AOF 重写卡顿等常见问题，在这个小版本上基本都补完了，但又没有引入新版本带来的新行为。所以很多生产环境在“不敢乱动”的前提下，会优先锁定这样一个次末代的稳定版。我之前处理过一个内部项目，业务代码里大量使用了 Lua 脚本加 Stream 消费，Redis 从 4.0 升到 5.0 的过程中基本没有感知，但后来测试 6.2 时发现某些边界条件下客户端重连的日志行为不同，排查成本一下就上来了。因此如果没有人明确要求新特性，选择 5.0.12 这类已经经过大量场景验证的版本，会省掉很多心智负担。

1.2 Docker 部署比裸机部署到底强在哪

很多人觉得 Docker 装 Redis 不就是把安装包换成了镜像，其实差别很大。裸机部署 Redis 时，你至少要关心系统里的依赖库、gcc 版本、编译参数、systemd 服务文件、日志轮转，甚至还要管理 Redis 进程崩溃后的守护逻辑。Docker 把这些全部封装到镜像里，你面对的接口只有一个：镜像名 + 版本号。这意味着本地开发和服务器部署用的是完全一致的操作系统层、编译参数和运行目录，极大减少“在我这是好的，到你那就跑不起来”的环境差异。

另外，Docker 让资源管控变得明确。你可以通过--memory限制 Redis 容器内存，防止单实例把宿主机内存吃满；可以通过--cpuset-cpus做 CPU 绑定；还可以通过独立的容器网络让 Redis 只对指定的应用容器可见，避免直接暴露到公网。这种隔离级别是裸机很难快速做到的。再加上删除重建容器几乎零成本，测试完一个配置方案后想回滚，再起一个新的就行，根本不会再看到环境残留的垃圾进程和配置文件。所以我认为只要是新部署的 Redis，用 Docker 包装是优先级很高的方案，除非你的场景强依赖 host 网络、或者有特殊内核模块需要直接加载，否则 Docker 完全够用且更好维护。

下表是我对裸机部署和容器部署几个维度的对比感受：

2. 环境检查与镜像拉取的几个细节

2.1 先把 Docker 基础环境确认好

任何部署动作之前，我都会先做一遍最基础的环境检查。原因很简单，很多后续异常根本不是 Redis 配置的问题，而是 Docker 服务本身有问题。先执行docker -v看版本，Red Hat 系发行版上 Docker 版本低于 19.03 的话我会建议先升级，因为旧版本对--restart策略、健康检查等特性的支持有明显差异，而且遇到容器异常退出时行为不够可靠。

接着用docker info查看 Docker 服务状态和存储驱动。如果这里直接报错，比如权限不足，说明当前用户不在 docker 用户组里，需要sudo usermod -aG docker 你的用户名然后重新登录；如果显示Cannot connect to the Docker daemon，多半是 Docker 服务没起来，先执行systemctl start docker。还有一个我经常见的环境坑：磁盘空间不足导致镜像拉取失败。Docker 默认的 root 目录可能和根分区共用空间，而 Redis 镜像虽然不算大，但 AOF 和 RDB 持久化数据增长很快，因此我在部署前会再瞄一眼df -h，确认/和/var/lib/docker所在分区有足够剩余空间。自己项目倒没什么，生产环境空间被瞬时写满导致容器崩溃的例子我见得太多了。

检查完基础环境后，最好顺手执行一下docker ps看看现存活容器，确认当前系统里有没有占用 6379 端口或者在跑其他 Redis 实例的残留容器。这一步虽然机械，但能避免后面端口映射冲突时排查半天。

2.2 镜像版本别拉错，官方镜像也要防“latest”

拉取 Redis 镜像我通常只认官方镜像，命令是docker pull redis:5.0.12。这里有一个非常容易踩的问题：如果只写docker pull redis，实际上拉的是 latest 标签，也就是官方仓库里最新的版本，在将来可能是 7.x 甚至更高的版本，这就和你写文档、做配置时参考的 5.0.12 行为完全对不上了。所以任何部署脚本和文档里，镜像标签一定写全。

除了默认的官方镜像，还有一个选择是redis:5.0.12-alpine。Alpine 版本镜像体积非常小，大概只有几十兆，适合磁盘紧张或追求启动速度的轻量场景。但我个人在生产里用得不多，原因有二：一是 Alpine 用的 musl libc 和 Ubuntu/Debian 的 glibc 在某些极端底层调用上有差异，部分第三方 Redis 模块如果是在 glibc 环境编译的，跑在 Alpine 镜像中可能行为异常；二是后来排查问题时，Alpine 里精简掉的调试工具会带来不便。如果你不是对体积特别敏感，优先用默认的 Debian 基础镜像版本。

拉取完成后，用docker images | grep redis确认镜像已经存在，并仔细核对 REPOSITORY 和 TAG 两列分别是redis和5.0.12。如果你处于内网离线环境，也可以提前在其他联网机器上把镜像导成 tar 包，再通过docker load导入，这里不多展开，但思路是成立的。

2.3 镜像加速器的配置与网络侧问题

如果你发现镜像拉取速度非常慢或者一直超时，先确认网络链路本身没问题，然后考虑 Docker 的镜像加速配置。这一步不涉及任何非常规网络操作，就是给 Docker daemon 配一个镜像加速地址，让拉取请求走更快的通道。

配置方法在/etc/docker/daemon.json中加一段：

{ "registry-mirrors": ["https://你的加速地址"] }

改完先执行systemctl daemon-reload，再systemctl restart docker。重新拉取时注意看拉取进度是否明显加快。这里要特别提醒：不同时期、不同地区的加速地址效果差异很大，如果你的网络环境访问官方仓库本身没问题，那就不需要配置这个，配置了反而可能因为加速器同步延迟而拉到一个缓存旧版本。每次拉取的关键操作是用完好的网络与最少变量去完成，其它东西能不动就不动。

3. 先把 redis.conf 准备到位，再去启动容器

3.1 宿主机目录规划：conf、data、logs 各司其职

容器跑起来容易，但要让 Redis 的数据和日志在容器销毁后依然保留，就必须把持久化目录挂载出来。我一般在宿主机上建立三个独立目录：

mkdir -p /opt/redis/conf mkdir -p /opt/redis/data mkdir -p /opt/redis/logs

有人会图省事只挂载 data 目录，配置文件直接写进镜像里或者每次启动时通过命令参数传入。这样短期没问题，但时间一长，别人看到容器里的配置时根本不知道这配置是从哪来的，也无法直接版本化。所以我建议 conf 目录单独放一份 redis.conf，管理上完全透明，修改后重启容器就能生效。logs 目录挂载出来的价值主要在于排查问题：Redis 容器本身默认会把日志打到标准输出，用docker logs能看到一部分，但如果出了问题容器频繁重启，日志被冲掉的风险比较大，直接落盘到宿主机目录更稳定。

目录权限在这里也要提前想好。Redis 容器内一般以redis用户运行，数据目录如果挂载出来，宿主机目录权限太严可能导致 Redis 无法写 RDB 或 AOF 文件。实际操作中如果遇到权限报错，直接执行chown -R 999:999 /opt/redis/data /opt/redis/logs能解决大部分情况，因为很多官方镜像里 redis 用户的 UID 是 999。当然更严谨的做法是先 exec 进容器里看一眼/etc/passwd，再按实际 UID 授权。

3.2 从容器里抄一份官方配置，再动刀精简

很多初学者会到处找 redis.conf 下载，其实最快也最权威的方式是从镜像里直接拷一份出来。先临时起一个容器：

docker run --name redis-temp -d redis:5.0.12 docker cp redis-temp:/etc/redis/redis.conf /opt/redis/conf/redis.conf docker rm -f redis-temp

拷贝完成后先别急着启动，因为官方原版配置默认情况下跑起来虽然能用，却不一定适合容器场景和生产需求。我一般会对这份配置做几处关键调整。先看这个我这个常用的最小化版本：

# 监听端口 port 6379 # 非常重要：不要后台化，否则容器会立即退出 daemonize no # 关闭保护模式，便于容器网络访问 protected-mode no # 默认监听所有网卡，配合端口映射使用 bind 0.0.0.0 # 访问密码，生产环境必须开 requirepass YourStrongPassword # 日志文件路径，留空表示输出到 stdout，同时可以配合容器日志驱动 logfile "" # 数据持久化目录 dir /data # RDB 快照规则 save 900 1 save 300 10 save 60 10000 # 开启 AOF 持久化 appendonly yes appendfilename "appendonly.aof" appendfsync everysec # 最大内存限制和淘汰策略 # maxmemory 256mb # maxmemory-policy allkeys-lru

这个配置里的daemonize no是整个容器方案里最核心的一行。我专门把这一条拉到最前面说，是因为 90% 用 Docker 跑 Redis 失败的新手都栽在这。Redis 默认配置里daemonize yes会让进程进入后台运行，但 Docker 容器的根进程一旦退出，整个容器就被判定为停止了。换句话说，如果 Redis 在容器内自己后台化了，容器立刻变成 Exited 状态，看起来就像刚启动就挂了。所以容器里必须前台运行，redis-server要一直占着 PID 1 的位置。

protected-mode这一项也要注意。默认值 yes 意味着如果 Redis 没有密码且监听了所有网卡，它会拒绝外部非本机连接。我们用 Docker 时通常要让其它容器或宿主机访问 Redis，所以会显式设置bind 0.0.0.0加protected-mode no，依靠端口映射来控制暴露范围。如果你同时设置了密码，其实保持protected-mode yes也是可以的，但配置判断逻辑多了以后反而容易误判，我习惯直接关掉保护模式，然后靠密码守护。

3.3 密码、持久化和淘汰策略的取舍思路

requirepass这一项建议直接启用，哪怕只是在测试环境。因为 Docker 端口映射一旦发布到宿主机，Redis 就处在了局域网甚至公网可达的位置，如果没有密码，等于把一台裸奔的服务丢在外面。Redis 官方也一直强调要通过防火墙和密码双重保护。密码设置我一般用强随机字符串，避免用 123456 这类弱口令，然后通过环境变量或挂载配置文件传入容器，不要把密码硬编码到 docker run 的进程列表里，因为那会出现在 shell history 和进程快照里。

持久化方面，我倾向于appendonly yes和 RDB 同时开启。AOF 对数据完整性的保障更强，恢复粒度更细；RDB 则更适合做快速备份和冷备归档。虽然两种都开会有一定的磁盘写放大，但 Redis 5.0 的 AOF 重写逻辑已经比较成熟，日常负载下影响不大。也许有人觉得只在内存里用一段时间，不需要持久化，那你可以关掉appendonly甚至把save规则全部注释，不过这属于临时缓存用法，和真正承担业务数据存储的场景是不同的运维思路。

淘汰策略属于一个“先配置好、未必立刻触发”的参数。如果 Redis 被当成缓存且内存上限固定，可以设maxmemory 256mb和maxmemory-policy allkeys-lru，让 Redis 在内存将满时自动淘汰最久未使用的 key。如果被当成数据库或消息中间件来用，默认不设上限也没问题，但系统层面需要配合监控防止内存被打爆。关键是要提前想清楚这一套 Redis 的使用定位，而不是盲目加参数。

4. 启动容器：docker run 全参数逐个拆解

4.1 一条经过实践检验的启动命令

配置文件准备好后，启动命令如下：

docker run -d \ --name redis-5.0.12 \ -p 6379:6379 \ -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /opt/redis/data:/data \ -v /opt/redis/logs:/logs \ --restart=always \ redis:5.0.12 \ redis-server /etc/redis/redis.conf

我拆开讲一下这些参数背后的逻辑。

-d表示后台运行容器，这个和daemonize no完全不冲突，因为-d是让容器后台运行，而 Redis 进程本身依然作为前台进程承载整个容器生命周期。

--name redis-5.0.12给容器起一个有意义的名字，后续docker exec、docker logs、docker stop都不用记一串随机 ID。

-p 6379:6379是端口映射，宿主机 6379 端口转发到容器内 6379 端口。这里左右两边的端口可以不相同，比如宿主上用 6380，可以写成-p 6380:6379，但客户端连接地址就要改成 6380。需要提醒的是，-p默认绑定0.0.0.0，也就是宿主机所有网卡接口都对外开放，如果只希望内网访问，建议写成-p 127.0.0.1:6379:6379，只绑定本机回环地址，这样其它机器无法直接访问，只有本机应用能连，安全性会好很多。

三个-v分别把宿主机上的 conf、data、logs 目录挂载进容器。这里有个顺序问题需要注意：数据目录挂载时，如果宿主机目录是空的，Docker 会把这个目录挂载为空的卷，容器里原有在/data下的数据不会被隐藏覆盖，但 Redis 启动时会在空目录里创建新的 RDB 和 AOF 文件。因此如果是从旧环境迁移数据，先把 dump.rdb 或 AOF 文件拷贝到/opt/redis/data下再启动容器，而不是反过来。

--restart=always是生产环境必备选项。它让 Docker 在宿主机重启或容器因异常退出时自动拉起 Redis。注意如果容器是被手动docker stop的，restart=always也不会自动重新拉起，Docker 尊重手动停止状态，这是预期行为。如果容器是因为 Redis 进程崩溃退出，--restart就会介入，几秒内重新启动。这个重启策略对 Redis 这种核心组件尤其重要，很多事故就是容器挂掉后没人及时发现，服务直接不可用。

最后一段redis-server /etc/redis/redis.conf是容器主进程的启动命令，意思是让 Redis 加载我们挂载进去的配置文件运行。不加这个参数的话，官方镜像默认会用内置命令redis-server启动，它不会主动读取我们挂载的位置，导致所有自定义配置全部失效，进入一个无密码、无持久化的裸奔状态。

4.2 为什么主进程必须用 redis-server 引导配置文件

这一条我觉得值得单独强调。不少人在官方镜像默认情况下只写了docker run -d redis:5.0.12，然后进去发现没有密码，配置也不生效，接着就开始怀疑是不是镜像的问题。实际上官方镜像的默认入口就是一个没有任何参数的redis-server，它加载的是 Redis 自身默认配置。我们挂载的/etc/redis/redis.conf如果没有被命令引用，就是纯粹放在那里当摆设。所以启动命令里redis-server /etc/redis/redis.conf才是真正让自定义配置生效的关键一步。

如果你想临时加一个配置项而不想改动配置文件，也可以写成：

docker run -d \ --name redis-5.0.12 \ -p 6379:6379 \ -v /opt/redis/data:/data \ redis:5.0.12 \ redis-server --appendonly yes --requirepass YourStrongPassword

这种方式用来临时验证配置很顺手，但缺点是不能持久化保存配置，肉眼看不出来之前用过哪些参数。所以我更建议把配置固化到文件里，用上面那套完整命令启动。

4.3 启动后的状态检查与基础连通性验证

启动完成后不要急着写业务代码，先看容器状态：

docker ps

如果docker ps里没有出现 redis-5.0.12，说明容器已经退出，立刻看日志：

docker logs redis-5.0.12

docker logs是最快定位问题的入口。如果看到Can't open the log file: Permission denied，说明 logs 目录权限不对，解决方式是调整目录属主；如果看到FATAL CONFIG FILE ERROR，说明配置里有语法错误或者无效参数，需要逐行检查 redis.conf；如果看到Could not create server TCP listening socket *:6379: bind: Address already in use，说明宿主机 6379 端口被占用，要么换映射端口，要么清理占用进程。

容器运行正常后再做一次连接测试。官方镜像自带redis-cli，通过docker exec直接进入容器环境操作是最干净的方式：

docker exec -it redis-5.0.12 redis-cli -a YourStrongPassword ping

返回PONG就说明 Redis 核心功能正常。接着可以看一些基本运行信息：

docker exec -it redis-5.0.12 redis-cli -a YourStrongPassword info

info返回特别长，但一开始只需要关注redis_version、uptime_in_seconds、connected_clients、used_memory、role。这些指标能快速确认实例版本、运行时长、内存占用和主从角色。

最后通过宿主机验证端口映射是否真的畅通。如果在宿主机装了 redis-cli，直接redis-cli -h 127.0.0.1 -p 6379 -a YourStrongPassword ping；没装的话可以执行：

docker run --rm -it --network host redis:5.0.12 redis-cli -h 127.0.0.1 -p 6379 -a YourStrongPassword ping

这一步确认的是网络链路，而不是容器内部功能。两者都验证通过，部署才算真正完成。

4.4 重启、停止与删除的常用管理操作

Redis 容器日常管理主要就是几个命令，背下来就行，但要理解每个命令的行为差异。

停止容器：

docker stop redis-5.0.12

这个命令会先给 Redis 发送 SIGTERM 信号，Redis 会尝试正常关闭，把内存中的数据刷到持久化文件，然后进程退出，容器停止。如果 10 秒内没有停止，Docker 才发 SIGKILL 强杀。注意，--restart=always不会打破这个逻辑，手动 stop 后容器保持 stopped。

启动容器：

docker start redis-5.0.12

重启容器，等价于 stop 再 start：

docker restart redis-5.0.12

修改了配置后我通常用docker restart加载新配置。如果只想验证一下配置语法，而不实际重启服务，可以用：

docker exec -it redis-5.0.12 redis-server /etc/redis/redis.conf --test-memory

不过--test-memory是内存测试，和配置检查不是一回事。真正检查配置文件有没有语法错误，可以先用一个临时容器挂载配置文件启动一次：

docker run --rm -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf redis:5.0.12 redis-server /etc/redis/redis.conf --check-config

如果输出没有报错，对应的语法就是好的。这个命令在生产环境换配置之前先跑一遍，能避免很多自杀式重启。

彻底删除容器（会连同容器本身的数据卷声明一起删掉，但宿主机挂载目录里的数据保留）：

docker rm -f redis-5.0.12

如果你确认不要这套数据了，再把/opt/redis/data下的持久化文件清空，否则再次启动时旧数据还会被加载，造成“明明换配置了，老 key 还在”的错觉。

5. 验证、性能检查与高频问题排查

5.1 用 redis-benchmark 做一次基础压测

部署完成后，做一次简单的压测能帮你确认实例的处理能力是否符合预期。官方镜像里带了一个redis-benchmark工具，一般用法如下：

docker exec -it redis-5.0.12 redis-benchmark -h 127.0.0.1 -p 6379 -a YourStrongPassword -n 100000 -c 50 -t set,get,lpush

参数含义不复杂：-n 100000表示总共发送 10 万条请求，-c 50表示用 50 个并发连接，-t set,get,lpush指定只测这三种操作。一次性跑完会输出每个操作的 QPS 和平均延迟。

第一次看到这份输出时别太兴奋，也不要太紧张。QPS 高低取决于宿主机 CPU 和网络环境，同一套 Redis 在不同机器上表现差异很大。关键是拿它作为基线，之后如果服务变慢，再跑一次对比才有参考价值。如果压测中出现大量超时，优先怀疑资源限制：检查docker stats redis-5.0.12，看看容器 CPU 和内存使用率是不是已经被打满；如果接近maxmemory上限且写操作触发淘汰策略，也会出现延迟升高。

5.2 容器内外连接失败的原因分布

我在实际帮别人排查时发现，容器内外连接不上 Redis 的原因通常集中在下面几个方面，我整理成表格方便对照：

其中MISCONF这个错误我需要单独展开说。Redis 的默认行为是：如果后台保存 RDB 快照失败，它会拒绝所有写请求，以此提醒运维人员及时处理。这种情况往往是磁盘空间满了，或者dir /data这个挂载点权限有问题。我见过有人用CONFIG SET stop-writes-on-bgsave-error no临时绕过这个保护，让 Redis 继续写入，但这是治标不治本的应急手段，根因不修复，数据安全始终是隐患。

5.3 内存、后台保存和容器退出相关的系统级参数

除了 Redis 自身配置，宿主机层面还有两个参数对 Redis 运行稳定性影响很大。第一个是内核的vm.overcommit_memory。Redis 在持久化时如果内存申请模式过度保守，可能出现后台保存失败，日志里会看到Background save process terminated by signal。一般建议设置：

sysctl -w vm.overcommit_memory=1

这个参数的意思是允许进程申请超过物理内存和交换空间总和的内存，对 Redis fork 子进程进行持久化时有明显帮助。要想永久生效，写入/etc/sysctl.conf里再sysctl -p。

第二个是内核参数net.core.somaxconn。Redis 默认监听套接字的 backlog 队列长度是 511，如果系统默认的 somaxconn 太小，高并发连接进来时会出现连接被拒绝。建议同样调大：

sysctl -w net.core.somaxconn=1024

这两个参数都是系统级调优，不区分裸机还是 Docker，因为容器和宿主机共享内核参数。很多东西如果你只盯着容器内部，可能永远找不到问题根源。

另外还有一个视觉上特别神秘的现象：容器启动后过了几秒就 Exited，日志里却干干净净。这种情况通常是配置里写了daemonize yes。Redis 进程自己 fork 到后台后，作为容器主进程的前台进程已经退出，容器自然就停了。这也再一次回到核心原则：容器里的 Redis 必须前台运行，daemonize no不能写成 yes。

5.4 修改配置后别踩的坑

我最后再分享一个很多人容易忽略的实操细节。配置文件修改后，执行docker restart redis-5.0.12前，最好先通过docker exec进入容器验证配置文件是否真的加载到了正确路径。你可以这样确认：

docker exec -it redis-5.0.12 redis-cli -a YourStrongPassword CONFIG GET maxmemory docker exec -it redis-5.0.12 redis-cli -a YourStrongPassword CONFIG GET appendonly

如果返回的结果里appendonly是yes，说明配置加载成功；如果显示no，那就是启动命令没有读取你挂载的配置文件，或者读取的是另一个路径。这种排查思路比反复重启容器高效得多，因为每个配置项都能精确对账，不会出现“以为改了但实际没生效”。

如果只是临时想改一个运行参数，不打算动配置文件，在线修改也能办到：

docker exec -it redis-5.0.12 redis-cli -a YourStrongPassword CONFIG SET maxmemory 512mb

但这种修改只会保留到 Redis 重启前。如果确认这个参数要长期生效，还是回归到改配置文件那一步，否则重启后一切打回原形。

最后想说的是，Docker 部署 Redis 本身不难，难的是你愿不愿意在启动之前把配置、目录、权限、网络、持久化这些细节想清楚。我最初几次部署也踩过daemonize yes导致容器秒退的坑，也见过生产环境因为logs目录没挂载、日志被容器清掉后无从排查的麻烦。但只要按这套流程走一遍，之后你再在任意一台机器上部署 Redis，基本上十分钟内就能交付一个稳定、可维护、数据安全的实例。这套组合我已经在很多环境里验证过了，你也可以放心直接照用。