Docker 里配置 Redis我自己前前后后折腾了不下十次。最早图省事直接docker run redis一把梭结果后面因为配置文件没有挂载、容器一删数据全没了、密码没设置被扫描器连进来写垃圾数据每一个坑都是真金白银买回来的教训。这篇文章就把我在本地开发和线上环境里用 Docker 跑 Redis 的完整思路、配置细节、实操命令和排错记录整理出来希望能帮你少走几趟弯路。文章会覆盖几个关键问题为什么推荐用 Docker 来跑 Redis 而不是直接装在宿主机redis.conf怎么挂载进容器并且真正生效端口、密码、持久化、资源限制这几类核心配置怎么选Docker Compose 怎么写最省事以及最常遇到的容器起不来、连接超时、数据丢失这类问题的排查方法。无论你是刚开始接触 Redis 的小白还是已经在用 Docker 部署服务的老手都可以对照着检查一下自己的配置习惯。1. 为什么建议用 Docker 跑 Redis1.1 容器化在 Redis 身上省了哪些事很多人第一次接触 Redis 都是在自己电脑上直接apt install redis-server或者下载编译源码装的。这种方式的痛点在项目多了以后会特别明显一是 Redis 版本混在一起A 项目用 5.xB 项目需要 7.x装来装去很容易把系统环境弄乱二是卸载不干净配置残留、数据目录残留、自动启动脚本残留全是麻烦三是换一台电脑或者换一台服务器整个安装过程要重新来一遍。Docker 把这些事情压缩成了两条命令docker pull redis和docker run redis。容器本身是隔离的镜像版本自己控制想用哪个版本就拉哪个版本互不干扰。删除的时候docker rm一把干完宿主机上干干净净。我自己的习惯是本地所有中间件服务——MySQL、Redis、RabbitMQ、Nginx——全部走 Docker宿主机只保留 Docker 和必要的开发工具。半年下来你会发现重装系统、迁移开发机这种事变得非常轻松。1.2 “一个容器一个职责”是配置的前提用 Docker 跑 Redis 有一条最基本的设计原则数据归数据配置归配置容器归容器。也就是说redis.conf要放在宿主机目录里挂载进容器持久化数据RDB 快照、AOF 文件也要落在宿主机目录里容器本身只负责运行进程。一开始我不懂这个把配置和数据都留在容器内部容器一删Redis 实例就“失忆”了。后来我养成了一个习惯每次部署 Redis 之前先建好一个固定的目录结构再决定docker run命令怎么写。目录结构通常是这样的/opt/redis/ ├── conf/ │ └── redis.conf └── data/ └── appendonlydir/conf放配置文件data放持久化数据。这样升级镜像、迁移服务器的时候只需要把这俩目录原样拷走再用同样的命令起一个新容器Redis 里的数据和服务配置全都还在业务侧完全无感。1.3 版本选择不能拍脑袋镜像版本这块我建议盯紧官方仓库里的 tag。目前大多数新项目可以直接用redis:7-alpine或者redis:7.2-alpine这类带具体次版本号的镜像。Alpine 版本体积小很多基础镜像只有几 MB 起步适合开发和一般业务场景。但要注意Alpine 用的 musl libc 在某些极端场景下表现和 glibc 略有差异如果你们业务里对 Redis 底层依赖非常敏感或者要跑 Redis 的模块扩展用默认的 Debian 版本更稳妥。生产环境里我不建议用latest它会在你不可控的某个时间点跳到新的大版本搞出一些意向不到的兼容问题。锁定一个你验证过的具体版本比如redis:7.2.5-alpine才是规范的做法。2. 基础配置与核心参数解析2.1 先动手拉起一个最简容器配置 Redis 之前你至少得先在 Docker 里把它跑起来试试。最基本的命令是docker run -d --name redis-test -p 6379:6379 redis:7-alpine这个命令做了四件事后台运行一个名为redis-test的容器把宿主机的 6379 端口映射到容器的 6379 端口使用redis:7-alpine镜像并让容器保持后台运行。启动完成后可以用下面的命令验证docker ps docker exec -it redis-test redis-cli ping正常情况下会返回PONG。很多第一次接触的同学会在这一步卡住常见原因是本地 6379 端口已经被宿主机上的 Redis 或者别的进程占了。处理办法很简单换一个映射端口比如-p 6380:6379宿主机用 6380容器内部依然是标准的 6379。2.2 配置文件为什么要挂载而不是进容器改默认情况下官方 Redis 镜像启动时会使用内置的默认配置。但你在容器里用vim改完配置容器一重建所有改动全部丢失。正确做法是把宿主机上的redis.conf挂载进容器并让容器启动时明确加载这个文件。挂载配置文件的命令长这样docker run -d \ --name redis \ -p 6379:6379 \ -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /opt/redis/data:/data \ redis:7-alpine \ redis-server /etc/redis/redis.conf注意最后一行镜像里默认的启动命令是redis-server但如果你写了配置文件路径它就会加载这个文件来启动。如果不写这个路径Redis 会无视你挂载进去的配置文件直接用内置默认配置跑起来这也是很多人“明明改了配置却不生效”的主要原因。2.3 redis.conf 里值得关注的几个关键项一份用于 Docker 环境的 Redis 配置文件不需要把官方文档里几百个参数全抄一遍但下面这些是命脉每一项都值得搞清楚。我整理了一张表方便对照配置项推荐值作用踩坑提醒bind0.0.0.0监听地址。容器内默认配置需要改为全地址不改的话外部客户端可能连不上protected-modeyes保护模式未设密码时限制外部访问设了密码后其实可以保留 yesport6379监听端口容器映射端口时可以改内部保持 6379 即可daemonizeno是否后台运行容器内必须为 no否则容器直接退出requirepass自定义强密码访问认证千万不能空着appendonlyyes开启 AOF 持久化不开启重启丢数据的风险极高appendfsynceverysecAOF 刷盘策略兼顾安全与性能的折中maxmemory视机器而定最大可用内存不设的话可能 OOM 拖垮宿主maxmemory-policyallkeys-lru内存满后的淘汰策略按业务类型选别乱用logfile/dev/stdout日志输出容器场景必须输出到 stdoutdaemonize这个参数害过我一次。在宿主机上直接跑 Redis默认配置里的daemonize yes没问题但在容器里如果写成 yesRedis 进程会把自身放入后台前台就没有进程了容器会立刻退出。容器场景下这个值必须写成no让 Redis 在前台运行容器才能保持存活。另一个容易忽视的是logfile。容器日志收集规范是让进程把日志打到标准输出Docker 会自动通过docker logs收集。所以logfile设置为/dev/stdout是容器内 Redis 的标准做法。如果把它写成一个文件路径日志会落在容器内部的临时层里容器一删日志就没了排查问题的时候格外被动。3. 完整实操从零搭建一个生产可用的 Redis 容器3.1 目录准备与配置文件编写先建目录sudo mkdir -p /opt/redis/conf sudo mkdir -p /opt/redis/data接下来在/opt/redis/conf/redis.conf里写入一份基础配置。我直接给一份我在用的模板你按需调整密码和内存上限bind 0.0.0.0 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised no pidfile /var/run/redis_6379.pid loglevel notice logfile /dev/stdout databases 16 requirepass your-strong-password save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb maxmemory 512mb maxmemory-policy allkeys-lru注意dir /data这个路径要和容器里挂载的数据目录对应上。AOF 文件和 RDB 文件都会写到这个目录里。3.2 启动容器并逐项验证配置是否生效配置文件就位后执行启动命令docker run -d \ --name redis \ --restartalways \ -p 6379:6379 \ -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf:ro \ -v /opt/redis/data:/data \ -e TZAsia/Shanghai \ redis:7-alpine \ redis-server /etc/redis/redis.conf这里加了--restartalways保证 Docker 重启、服务器重启后容器能自动拉起来。配置挂载加:ro是防止容器里误改配置文件宿主机上的版本才是唯一可信源。启动后验证配置是否真正生效我习惯按顺序执行这几条docker ps docker exec -it redis redis-cli -a your-strong-password ping docker exec -it redis redis-cli -a your-strong-password config get requirepass docker exec -it redis redis-cli -a your-strong-password config get appendonly第一条确认容器在跑第二条确认认证生效第三四条确认关键配置和我们的预期一致。如果config get拿回来的值和配置文件里写的不一样说明配置文件没有被加载优先检查挂载路径和启动命令里的redis-server参数。3.3 数据持久化配置与日常备份思路Redis 落盘有两种机制。RDB 是定期生成一个二进制快照恢复速度快但最后一次快照之后的数据可能丢失AOF 是追加写入文件按策略刷盘最多丢 1 秒的数据。真线上建议两个都开RDB 负责快速恢复兜底AOF 负责把数据完整性兜住。appendfsync的三个值需要自己权衡取值安全性性能适用场景always最安全每次写都刷盘最慢对数据绝对敏感且写量很小的场景everysec最多丢 1 秒数据折中绝大多数常规业务我用最多no由操作系统决定刷盘最快能接受较大量数据丢失的缓存场景备份策略不要等出事了再想。我每周会做一次离线备份命令是docker exec -it redis redis-cli -a your-strong-password BGSAVE sudo cp /opt/redis/data/dump.rdb /backup/redis/redis-$(date %F).rdbBGSAVE是后台触发一次 RDB 快照不会阻塞 Redis。备份完的dump.rdb文件拷走之后异地或者对象存储再放一份。恢复的时候把备份文件放回数据目录里重启容器即可。3.4 用 Docker Compose 管理更省心命令行的方式适合单机快速验证但如果你的 Redis 还涉及网络、多个容器协作强烈建议直接上 Docker Compose。写一个docker-compose.ymlservices: redis: image: redis:7-alpine container_name: redis restart: always ports: - 6379:6379 volumes: - /opt/redis/conf/redis.conf:/etc/redis/redis.conf:ro - /opt/redis/data:/data command: [redis-server, /etc/redis/redis.conf] environment: - TZAsia/Shanghai使用方式docker compose up -d docker compose ps docker compose logs -f redisCompose 文件的好处是一次定义到处复用。换了新服务器把docker-compose.yml和conf、data目录整体搬过去docker compose up -d一条命令整个 Redis 服务就和原来一模一样。这比每次手敲一长串docker run参数靠谱得多也方便团队里其他人接手。4. 常见问题与排查技巧实录4.1 容器启动秒退怎么定位最典型的症状是docker run之后容器马上退出docker ps看不到docker ps -a看到状态是Exited (1)或者Exited (0)。这时候先看日志docker logs redis日志里会出现两类高频原因。一类是找不到配置文件提示Cant open the config file去检查容器内路径和挂载关系或者你根本没有把配置文件放进宿主机目录另一类是权限问题提示Cant chdir to /data通常是数据目录的所有者和容器里运行 Redis 的用户不一致导致的。权限问题有个粗暴但实用的处理方式chown -R 999:999 /opt/redisRedis 官方镜像是用redis用户运行的UID 通常是 999。把宿主机挂载目录改成 999 所有就能避免容器内没权限写数据的情况。每次新建目录挂载完我都会顺手做这一步免得后面回忆“刚才是不是忘了授权”。4.2 宿主机连接不上排查思路是什么容器起来了但宿主机上用redis-cli -h 127.0.0.1 -p 6379 ping一直超时或拒绝。我会把排查链路拆成四层容器是否在运行docker ps。端口映射是否存在docker port redis看看有没有正确的6379/tcp - 0.0.0.0:6379输出。容器内是否正常docker exec redis redis-cli ping如果容器内返回PONG说明 Redis 本身没毛病。宿主机防火墙和 bind 配置检查bind是否为0.0.0.0以及服务器安全组、防火墙是否放行了 6379。还有一个极隐蔽的情况配置文件里写了bind 127.0.0.1容器外部从宿主机访问时请求能到达容器网络但 Redis 只在自己的回环地址上监听连接直接被拒绝。所以我在容器脚本里统一用bind 0.0.0.0保障层交给防火墙和密码。4.3 数据“丢失”到底丢在了哪里很多人反馈“容器重启后 Redis 里数据全没了”。绝大多数情况不是 Redis 出 bug而是数据根本没有落到宿主机。原因基本是两个第一appendonly是no容器一停内存里的数据没来得及生成快照就没了第二启动命令里没有挂载-v /opt/redis/data:/data数据写进了容器自己的可写层容器一删除就跟着消失。判断数据是否落在了宿主目录可以随时看这个目录的大小和内容变化ls -lh /opt/redis/data/如果目录是空的或者只有容器创建时生成的文件那就要检查挂载和配置了。我自己的习惯是任何 Redis 容器都必须满足“数据目录非空且持续变大”这个基本条件否则就把它当成不稳定实例处理绝不投入使用。4.4 Redis 报连接超时不一定只是网络问题热词里有一条redis command timed out; nested exception is io.lettuce.core.rediscommandtimeout这是 Spring Boot 项目用 Lettuce 连接 Redis 时非常经典的一类报错。遇到它首先排查网络从应用机器 telnet Redis 端口是否通。通了以后再排查 Redis 自身slowlog get看看有没有慢命令INFO stats看看连接数是否被占满。如果确认 Redis 负载很高命令排队超时就要从配置层面下手。maxmemory是否设置合理淘汰策略是不是选错导致频繁淘汰连接池参数是不是开得太大把 Redis 的连接打满了AOF 刷盘策略是不是太激进每次写都要等磁盘 IO。这类问题没有银弹配置只能根据监控数据慢慢调。4.5 附一张高频问题速查表现象优先排查项一句话处理建议容器 Exited (0)daemonize是否误设为 yes改成 no 后用配置文件启动容器 Exited (1) 且提示 config 打不开挂载路径或命令参数核对-v路径与redis-server 参数容器 Exited (1) 且提示Cant chdir数据目录权限chown -R 999:999 /opt/redis外部连接超时端口映射、防火墙、binddocker port redis逐个排查重启数据全丢未挂载数据卷检查-v挂载与dir /dataSpring Boot 超时Redis 负载与慢命令slowlog、INFO看指标再调参5. 进阶主从复制与高可用雏形5.1 用 Docker 快速搭一主一从业务量上来之后单节点 Redis 既要扛读写又要担心宕机这时候可以先做一主一从。用 Docker 做这个实验特别方便先建一个自定义网络让容器之间可以互访docker network create redis-net主节点配置不用动从节点的redis.conf里加一行replicaof redis-master 6379同时把从节点的dir /data和数据目录配好。启动命令里把从节点容器加入同一个网络并配置主节点的访问密码。这里有个很容易忽略的细节如果主节点设置了requirepass从节点的配置里同时要加上masterauth否则从节点会一直尝试同步但永远认证失败日志里反复刷MASTER aborted replication with an error: NOAUTH Authentication required。验证主从是否正常docker exec -it redis-slave redis-cli -a your-strong-password INFO replication看到role:slave并且master_link_status:up说明同步链路正常。5.2 连接工具与密码安全建议开发调试阶段图形化工具能省不少事。Redis Desktop Manager 和 Redis Insight 我都用过。Redis Insight 是官方出的功能更新勤快支持内存分析、命令监控我个人日常用得更多。连接的时候填宿主机的 IP、映射端口和密码即可。用工具连接之前一定要确认 Redis 的密码是强密码至少 16 位以上包含大小写字母、数字和特殊符号。很多被挖矿程序盯上的 Redis 实例都是因为密码为空或者弱口令加上bind 0.0.0.0暴露在公网。安全配置有个基本公式强密码加保护模式加防火墙白名单三层缺一不可。6. 聊点实际经验总结写到这我想起有一次线上事故。同事图方便在测试环境直接docker run redis没挂数据和配置。后来测试环境容器被回收Redis 里存了一周的缓存和临时业务数据全没了虽然只是测试环境排查问题也花了大半天。后来我就立了一个规矩凡是用 Docker 跑 Redis不管是生产还是测试都按同一套标准来——配置文件挂载、数据目录挂载、密码必填、持久化必开、--restartalways必加。还有一个小技巧值得分享每次写完新的redis.conf我都会用docker exec -it redis redis-cli CONFIG REWRITE这个命令来确认当前运行时配置和文件配置是否一致。这个命令会把容器内实际生效的配置重写到配置文件里如果文件挂载是只读的它会报只读错误反而是个快速校验的好办法。当然线上环境我一般不会真的执行它只是把它当作排查工具用。Docker 加 Redis 的组合本质是把 Redis 从“安装在系统里的服务”变成了“一个可以随时复制的应用单元”。只要把配置文件、数据目录、启动方式这三样管好Redis 容器就能在各种环境里无缝迁移。这套玩法沉淀下来之后你会发现自己省下的时间远超当初学习 Docker 的投入。 Docker 部署 Redis 完整指南：配置挂载、持久化与排错实战
Docker 里配置 Redis我自己前前后后折腾了不下十次。最早图省事直接docker run redis一把梭结果后面因为配置文件没有挂载、容器一删数据全没了、密码没设置被扫描器连进来写垃圾数据每一个坑都是真金白银买回来的教训。这篇文章就把我在本地开发和线上环境里用 Docker 跑 Redis 的完整思路、配置细节、实操命令和排错记录整理出来希望能帮你少走几趟弯路。文章会覆盖几个关键问题为什么推荐用 Docker 来跑 Redis 而不是直接装在宿主机redis.conf怎么挂载进容器并且真正生效端口、密码、持久化、资源限制这几类核心配置怎么选Docker Compose 怎么写最省事以及最常遇到的容器起不来、连接超时、数据丢失这类问题的排查方法。无论你是刚开始接触 Redis 的小白还是已经在用 Docker 部署服务的老手都可以对照着检查一下自己的配置习惯。1. 为什么建议用 Docker 跑 Redis1.1 容器化在 Redis 身上省了哪些事很多人第一次接触 Redis 都是在自己电脑上直接apt install redis-server或者下载编译源码装的。这种方式的痛点在项目多了以后会特别明显一是 Redis 版本混在一起A 项目用 5.xB 项目需要 7.x装来装去很容易把系统环境弄乱二是卸载不干净配置残留、数据目录残留、自动启动脚本残留全是麻烦三是换一台电脑或者换一台服务器整个安装过程要重新来一遍。Docker 把这些事情压缩成了两条命令docker pull redis和docker run redis。容器本身是隔离的镜像版本自己控制想用哪个版本就拉哪个版本互不干扰。删除的时候docker rm一把干完宿主机上干干净净。我自己的习惯是本地所有中间件服务——MySQL、Redis、RabbitMQ、Nginx——全部走 Docker宿主机只保留 Docker 和必要的开发工具。半年下来你会发现重装系统、迁移开发机这种事变得非常轻松。1.2 “一个容器一个职责”是配置的前提用 Docker 跑 Redis 有一条最基本的设计原则数据归数据配置归配置容器归容器。也就是说redis.conf要放在宿主机目录里挂载进容器持久化数据RDB 快照、AOF 文件也要落在宿主机目录里容器本身只负责运行进程。一开始我不懂这个把配置和数据都留在容器内部容器一删Redis 实例就“失忆”了。后来我养成了一个习惯每次部署 Redis 之前先建好一个固定的目录结构再决定docker run命令怎么写。目录结构通常是这样的/opt/redis/ ├── conf/ │ └── redis.conf └── data/ └── appendonlydir/conf放配置文件data放持久化数据。这样升级镜像、迁移服务器的时候只需要把这俩目录原样拷走再用同样的命令起一个新容器Redis 里的数据和服务配置全都还在业务侧完全无感。1.3 版本选择不能拍脑袋镜像版本这块我建议盯紧官方仓库里的 tag。目前大多数新项目可以直接用redis:7-alpine或者redis:7.2-alpine这类带具体次版本号的镜像。Alpine 版本体积小很多基础镜像只有几 MB 起步适合开发和一般业务场景。但要注意Alpine 用的 musl libc 在某些极端场景下表现和 glibc 略有差异如果你们业务里对 Redis 底层依赖非常敏感或者要跑 Redis 的模块扩展用默认的 Debian 版本更稳妥。生产环境里我不建议用latest它会在你不可控的某个时间点跳到新的大版本搞出一些意向不到的兼容问题。锁定一个你验证过的具体版本比如redis:7.2.5-alpine才是规范的做法。2. 基础配置与核心参数解析2.1 先动手拉起一个最简容器配置 Redis 之前你至少得先在 Docker 里把它跑起来试试。最基本的命令是docker run -d --name redis-test -p 6379:6379 redis:7-alpine这个命令做了四件事后台运行一个名为redis-test的容器把宿主机的 6379 端口映射到容器的 6379 端口使用redis:7-alpine镜像并让容器保持后台运行。启动完成后可以用下面的命令验证docker ps docker exec -it redis-test redis-cli ping正常情况下会返回PONG。很多第一次接触的同学会在这一步卡住常见原因是本地 6379 端口已经被宿主机上的 Redis 或者别的进程占了。处理办法很简单换一个映射端口比如-p 6380:6379宿主机用 6380容器内部依然是标准的 6379。2.2 配置文件为什么要挂载而不是进容器改默认情况下官方 Redis 镜像启动时会使用内置的默认配置。但你在容器里用vim改完配置容器一重建所有改动全部丢失。正确做法是把宿主机上的redis.conf挂载进容器并让容器启动时明确加载这个文件。挂载配置文件的命令长这样docker run -d \ --name redis \ -p 6379:6379 \ -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /opt/redis/data:/data \ redis:7-alpine \ redis-server /etc/redis/redis.conf注意最后一行镜像里默认的启动命令是redis-server但如果你写了配置文件路径它就会加载这个文件来启动。如果不写这个路径Redis 会无视你挂载进去的配置文件直接用内置默认配置跑起来这也是很多人“明明改了配置却不生效”的主要原因。2.3 redis.conf 里值得关注的几个关键项一份用于 Docker 环境的 Redis 配置文件不需要把官方文档里几百个参数全抄一遍但下面这些是命脉每一项都值得搞清楚。我整理了一张表方便对照配置项推荐值作用踩坑提醒bind0.0.0.0监听地址。容器内默认配置需要改为全地址不改的话外部客户端可能连不上protected-modeyes保护模式未设密码时限制外部访问设了密码后其实可以保留 yesport6379监听端口容器映射端口时可以改内部保持 6379 即可daemonizeno是否后台运行容器内必须为 no否则容器直接退出requirepass自定义强密码访问认证千万不能空着appendonlyyes开启 AOF 持久化不开启重启丢数据的风险极高appendfsynceverysecAOF 刷盘策略兼顾安全与性能的折中maxmemory视机器而定最大可用内存不设的话可能 OOM 拖垮宿主maxmemory-policyallkeys-lru内存满后的淘汰策略按业务类型选别乱用logfile/dev/stdout日志输出容器场景必须输出到 stdoutdaemonize这个参数害过我一次。在宿主机上直接跑 Redis默认配置里的daemonize yes没问题但在容器里如果写成 yesRedis 进程会把自身放入后台前台就没有进程了容器会立刻退出。容器场景下这个值必须写成no让 Redis 在前台运行容器才能保持存活。另一个容易忽视的是logfile。容器日志收集规范是让进程把日志打到标准输出Docker 会自动通过docker logs收集。所以logfile设置为/dev/stdout是容器内 Redis 的标准做法。如果把它写成一个文件路径日志会落在容器内部的临时层里容器一删日志就没了排查问题的时候格外被动。3. 完整实操从零搭建一个生产可用的 Redis 容器3.1 目录准备与配置文件编写先建目录sudo mkdir -p /opt/redis/conf sudo mkdir -p /opt/redis/data接下来在/opt/redis/conf/redis.conf里写入一份基础配置。我直接给一份我在用的模板你按需调整密码和内存上限bind 0.0.0.0 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised no pidfile /var/run/redis_6379.pid loglevel notice logfile /dev/stdout databases 16 requirepass your-strong-password save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb maxmemory 512mb maxmemory-policy allkeys-lru注意dir /data这个路径要和容器里挂载的数据目录对应上。AOF 文件和 RDB 文件都会写到这个目录里。3.2 启动容器并逐项验证配置是否生效配置文件就位后执行启动命令docker run -d \ --name redis \ --restartalways \ -p 6379:6379 \ -v /opt/redis/conf/redis.conf:/etc/redis/redis.conf:ro \ -v /opt/redis/data:/data \ -e TZAsia/Shanghai \ redis:7-alpine \ redis-server /etc/redis/redis.conf这里加了--restartalways保证 Docker 重启、服务器重启后容器能自动拉起来。配置挂载加:ro是防止容器里误改配置文件宿主机上的版本才是唯一可信源。启动后验证配置是否真正生效我习惯按顺序执行这几条docker ps docker exec -it redis redis-cli -a your-strong-password ping docker exec -it redis redis-cli -a your-strong-password config get requirepass docker exec -it redis redis-cli -a your-strong-password config get appendonly第一条确认容器在跑第二条确认认证生效第三四条确认关键配置和我们的预期一致。如果config get拿回来的值和配置文件里写的不一样说明配置文件没有被加载优先检查挂载路径和启动命令里的redis-server参数。3.3 数据持久化配置与日常备份思路Redis 落盘有两种机制。RDB 是定期生成一个二进制快照恢复速度快但最后一次快照之后的数据可能丢失AOF 是追加写入文件按策略刷盘最多丢 1 秒的数据。真线上建议两个都开RDB 负责快速恢复兜底AOF 负责把数据完整性兜住。appendfsync的三个值需要自己权衡取值安全性性能适用场景always最安全每次写都刷盘最慢对数据绝对敏感且写量很小的场景everysec最多丢 1 秒数据折中绝大多数常规业务我用最多no由操作系统决定刷盘最快能接受较大量数据丢失的缓存场景备份策略不要等出事了再想。我每周会做一次离线备份命令是docker exec -it redis redis-cli -a your-strong-password BGSAVE sudo cp /opt/redis/data/dump.rdb /backup/redis/redis-$(date %F).rdbBGSAVE是后台触发一次 RDB 快照不会阻塞 Redis。备份完的dump.rdb文件拷走之后异地或者对象存储再放一份。恢复的时候把备份文件放回数据目录里重启容器即可。3.4 用 Docker Compose 管理更省心命令行的方式适合单机快速验证但如果你的 Redis 还涉及网络、多个容器协作强烈建议直接上 Docker Compose。写一个docker-compose.ymlservices: redis: image: redis:7-alpine container_name: redis restart: always ports: - 6379:6379 volumes: - /opt/redis/conf/redis.conf:/etc/redis/redis.conf:ro - /opt/redis/data:/data command: [redis-server, /etc/redis/redis.conf] environment: - TZAsia/Shanghai使用方式docker compose up -d docker compose ps docker compose logs -f redisCompose 文件的好处是一次定义到处复用。换了新服务器把docker-compose.yml和conf、data目录整体搬过去docker compose up -d一条命令整个 Redis 服务就和原来一模一样。这比每次手敲一长串docker run参数靠谱得多也方便团队里其他人接手。4. 常见问题与排查技巧实录4.1 容器启动秒退怎么定位最典型的症状是docker run之后容器马上退出docker ps看不到docker ps -a看到状态是Exited (1)或者Exited (0)。这时候先看日志docker logs redis日志里会出现两类高频原因。一类是找不到配置文件提示Cant open the config file去检查容器内路径和挂载关系或者你根本没有把配置文件放进宿主机目录另一类是权限问题提示Cant chdir to /data通常是数据目录的所有者和容器里运行 Redis 的用户不一致导致的。权限问题有个粗暴但实用的处理方式chown -R 999:999 /opt/redisRedis 官方镜像是用redis用户运行的UID 通常是 999。把宿主机挂载目录改成 999 所有就能避免容器内没权限写数据的情况。每次新建目录挂载完我都会顺手做这一步免得后面回忆“刚才是不是忘了授权”。4.2 宿主机连接不上排查思路是什么容器起来了但宿主机上用redis-cli -h 127.0.0.1 -p 6379 ping一直超时或拒绝。我会把排查链路拆成四层容器是否在运行docker ps。端口映射是否存在docker port redis看看有没有正确的6379/tcp - 0.0.0.0:6379输出。容器内是否正常docker exec redis redis-cli ping如果容器内返回PONG说明 Redis 本身没毛病。宿主机防火墙和 bind 配置检查bind是否为0.0.0.0以及服务器安全组、防火墙是否放行了 6379。还有一个极隐蔽的情况配置文件里写了bind 127.0.0.1容器外部从宿主机访问时请求能到达容器网络但 Redis 只在自己的回环地址上监听连接直接被拒绝。所以我在容器脚本里统一用bind 0.0.0.0保障层交给防火墙和密码。4.3 数据“丢失”到底丢在了哪里很多人反馈“容器重启后 Redis 里数据全没了”。绝大多数情况不是 Redis 出 bug而是数据根本没有落到宿主机。原因基本是两个第一appendonly是no容器一停内存里的数据没来得及生成快照就没了第二启动命令里没有挂载-v /opt/redis/data:/data数据写进了容器自己的可写层容器一删除就跟着消失。判断数据是否落在了宿主目录可以随时看这个目录的大小和内容变化ls -lh /opt/redis/data/如果目录是空的或者只有容器创建时生成的文件那就要检查挂载和配置了。我自己的习惯是任何 Redis 容器都必须满足“数据目录非空且持续变大”这个基本条件否则就把它当成不稳定实例处理绝不投入使用。4.4 Redis 报连接超时不一定只是网络问题热词里有一条redis command timed out; nested exception is io.lettuce.core.rediscommandtimeout这是 Spring Boot 项目用 Lettuce 连接 Redis 时非常经典的一类报错。遇到它首先排查网络从应用机器 telnet Redis 端口是否通。通了以后再排查 Redis 自身slowlog get看看有没有慢命令INFO stats看看连接数是否被占满。如果确认 Redis 负载很高命令排队超时就要从配置层面下手。maxmemory是否设置合理淘汰策略是不是选错导致频繁淘汰连接池参数是不是开得太大把 Redis 的连接打满了AOF 刷盘策略是不是太激进每次写都要等磁盘 IO。这类问题没有银弹配置只能根据监控数据慢慢调。4.5 附一张高频问题速查表现象优先排查项一句话处理建议容器 Exited (0)daemonize是否误设为 yes改成 no 后用配置文件启动容器 Exited (1) 且提示 config 打不开挂载路径或命令参数核对-v路径与redis-server 参数容器 Exited (1) 且提示Cant chdir数据目录权限chown -R 999:999 /opt/redis外部连接超时端口映射、防火墙、binddocker port redis逐个排查重启数据全丢未挂载数据卷检查-v挂载与dir /dataSpring Boot 超时Redis 负载与慢命令slowlog、INFO看指标再调参5. 进阶主从复制与高可用雏形5.1 用 Docker 快速搭一主一从业务量上来之后单节点 Redis 既要扛读写又要担心宕机这时候可以先做一主一从。用 Docker 做这个实验特别方便先建一个自定义网络让容器之间可以互访docker network create redis-net主节点配置不用动从节点的redis.conf里加一行replicaof redis-master 6379同时把从节点的dir /data和数据目录配好。启动命令里把从节点容器加入同一个网络并配置主节点的访问密码。这里有个很容易忽略的细节如果主节点设置了requirepass从节点的配置里同时要加上masterauth否则从节点会一直尝试同步但永远认证失败日志里反复刷MASTER aborted replication with an error: NOAUTH Authentication required。验证主从是否正常docker exec -it redis-slave redis-cli -a your-strong-password INFO replication看到role:slave并且master_link_status:up说明同步链路正常。5.2 连接工具与密码安全建议开发调试阶段图形化工具能省不少事。Redis Desktop Manager 和 Redis Insight 我都用过。Redis Insight 是官方出的功能更新勤快支持内存分析、命令监控我个人日常用得更多。连接的时候填宿主机的 IP、映射端口和密码即可。用工具连接之前一定要确认 Redis 的密码是强密码至少 16 位以上包含大小写字母、数字和特殊符号。很多被挖矿程序盯上的 Redis 实例都是因为密码为空或者弱口令加上bind 0.0.0.0暴露在公网。安全配置有个基本公式强密码加保护模式加防火墙白名单三层缺一不可。6. 聊点实际经验总结写到这我想起有一次线上事故。同事图方便在测试环境直接docker run redis没挂数据和配置。后来测试环境容器被回收Redis 里存了一周的缓存和临时业务数据全没了虽然只是测试环境排查问题也花了大半天。后来我就立了一个规矩凡是用 Docker 跑 Redis不管是生产还是测试都按同一套标准来——配置文件挂载、数据目录挂载、密码必填、持久化必开、--restartalways必加。还有一个小技巧值得分享每次写完新的redis.conf我都会用docker exec -it redis redis-cli CONFIG REWRITE这个命令来确认当前运行时配置和文件配置是否一致。这个命令会把容器内实际生效的配置重写到配置文件里如果文件挂载是只读的它会报只读错误反而是个快速校验的好办法。当然线上环境我一般不会真的执行它只是把它当作排查工具用。Docker 加 Redis 的组合本质是把 Redis 从“安装在系统里的服务”变成了“一个可以随时复制的应用单元”。只要把配置文件、数据目录、启动方式这三样管好Redis 容器就能在各种环境里无缝迁移。这套玩法沉淀下来之后你会发现自己省下的时间远超当初学习 Docker 的投入。