1. 为什么我坚持用Docker跑Redis从环境污染说到秒级回滚先聊个实际场景。早几年我在一台开发机上装Redis还是老老实实下载源码编译那套流程。等到换电脑、换公司发现一个问题Redis版本升级了、配置文件改乱了、或者干脆启动不起来了排查起来非常痛苦。更麻烦的是你为了解一个Redis特性可能要同时维护好几个版本的实例本机环境很快就变成一锅粥。后来切到Docker之后这个痛点彻底解决。拉一个redis镜像docker run一跑一个干净、隔离的Redis环境就有了。想换版本换镜像标签就行两分钟搞定。配置文件改崩了删掉容器重新起一个秒级回滚。这里我说的环境不只是Redis本身还包括它的系统依赖、编译参数、运行目录Docker把这些全部封装进镜像换到任何一台装有Docker的机器上行为都是一模一样的。这篇内容适合谁看首先是想快速在本地搭一个Redis环境做开发测试的同学其次是准备上生产环境但不想被编译安装、系统服务配置、多实例冲突折磨的运维或后端朋友。我会从零开始讲就算你之前完全没用过Docker只要照着步骤来也能把Redis跑起来并且理解每一步在干什么。借用我之前折腾Docker Desktop踩坑、在服务器上跑Redis容器的经验把从环境准备、容器创建、日常运维到主从搭建、可视化连接、常见报错解决这整条链路完整拆开尽量把话说透做一次彻底分享。2. Docker环境准备跑Redis前先把Docker本身搞定2.1 Windows上安装Docker Desktop最容易踩的虚拟化坑Windows下想用Docker跑Redis绝大多数人都会装Docker Desktop。安装包下载、双击、安装看似平平无奇但启动的时候经常会看到一个让人血压升高的报错Docker Desktop failed to start because virtualisation support wasnt detected.这个报错在热搜词里频繁出现也是Windows环境最典型的一道坎。它的本质是Docker Desktop在Windows上依赖WSL2或者Hyper-V来运行Linux容器而这两者都需要CPU虚拟化VT-x/AMD-V支持且处于开启状态。我的排查顺序一般是这样的打开任务管理器切到性能标签看右下角虚拟化一栏是不是已启用。如果显示已禁用那问题大概率出在BIOS/UEFI设置里需要重启进BIOS开机按Del或F2不同主板键位不同在Advanced/CPU Configuration里找Intel Virtualization Technology或SVM Mode改成Enabled。如果BIOS里已经开了虚拟化但Docker Desktop还是报这个错就检查Windows功能里有没有启用虚拟机平台和适用于Linux的Windows子系统。控制面板 - 程序和功能 - 启用或关闭Windows功能把这两项勾上重启电脑。还有一类场景是Windows 10较老的版本对WSL2支持不太好建议直接wsl --update升级到最新内核然后wsl --set-default-version 2。这套组合拳打完Docker Desktop基本能正常启动。哪怕你已经用上了vmware或者VirtualBox只要开了嵌套虚拟化一般也不会有冲突。实测下来Windows 11 WSL2 Docker Desktop这个组合跑Redis非常顺滑性能和原生Linux差距很小至少日常开发完全够用。2.2 Linux/macOS下的Docker安装差异如果用的是macOS尤其现在M系列芯片Docker Desktop同样适用直接下载对应芯片版本即可基本不需要折腾。真正要注意的是Homebrew装Redis和Docker跑Redis的区别Homebrew装的Redis是跑在宿主机上的配置文件、数据目录、日志都散落在系统目录里Docker跑Redis一切都在容器内宿主干净得很。Linux服务器上则有两种安装方式。一种是直接用官方脚本curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable --now docker另一种是使用发行版自带的包管理器比如Ubuntu下sudo apt update sudo apt install docker.io sudo systemctl enable --now docker两者最终差别不大但官方脚本通常会带上最新版而apt源里的docker.io版本可能偏旧。对跑Redis这种场景来说版本差异不会造成明显体验区别挑顺手的装就行。装完之后顺手验证一下docker version docker run hello-world第一条能看到客户端和服务端版本信息第二条能确认拉取镜像和运行容器的链路是通的。3. 创建Redis容器逐参数拆解一条完整的docker run命令3.1 镜像拉取官方Redis镜像的版本选择逻辑环境就绪后的第一个动作是拉镜像。Redis官方镜像就在Docker Hub上直接docker pull redis:7.2这里有个值得多说一句的点镜像标签的选择。redis:latest虽然看起来省事但latest是一个浮动标签哪天重新拉取可能就变了。我见过有同事早上起来发现Redis从6.x变成了7.x一些底层行为变化导致缓存数据序列化方式不兼容排查半天。所以我的习惯是锁定一个具体的次要版本比如redis:7.2既保证有修复补丁又不会意外跳版本。至于为什么选7.x而不是6.x主要是7.0引入了Redis Functions用脚本逻辑取代部分Lua脚本场景、AOF三段式混合持久化等一系列优化对日常使用来说更省心。当然生产环境如果有历史包袱沿用团队已熟悉的版本是更稳妥的选择这没有绝对的对错。3.2 配置挂载、数据持久化、密码认证完整命令逐项注释拉完镜像创建容器的核心命令长这样docker run -d \ --name redis-server \ -p 6379:6379 \ -v /Users/you/docker/redis/data:/data \ -v /Users/you/docker/redis/conf/redis.conf:/etc/redis/redis.conf \ --restart unless-stopped \ -e TZAsia/Shanghai \ redis:7.2 \ redis-server /etc/redis/redis.conf每个参数用大白话解释一下-d后台运行不然终端会被日志刷屏一旦关掉SSH容器可能跟着退出。--name redis-server给容器起个名字。后续docker logs redis-server、docker restart redis-server全靠它省得记一长串容器ID。-p 6379:6379端口映射。宿主机6379端口映射到容器内Redis的6379端口。左边的6379是外面访问用的端口右边是Redis默认监听端口。如果你不想让别人轻易扫到这个端口可以把左边改成一个冷门端口比如-p 16379:6379连接时指向16379即可。-v .../data:/data数据目录挂载。Redis的RDB快照和AOF文件默认写在容器内的/data目录。如果不挂载容器一旦删除所有数据瞬间归零。挂载到宿主机目录后就算Redis容器被删数据还在宿主机上卷土重来毫不费力。-v .../redis.conf:/etc/redis/redis.conf配置文件挂载。用宿主机的配置去覆盖容器内的默认配置。注意Redis容器内是不自带redis.conf的官方镜像把默认配置编译进了二进制里所以我们需要自行准备一个配置文件。--restart unless-stopped容器退出后自动重启排除人为stop的情况。服务器重启后Docker自动把容器拉起来对跑在云服务器上的Redis非常友好。-e TZAsia/Shanghai设置时区。Redis日志时间戳默认用UTC跟北京差8小时排查线上问题的时候容易把自己绕晕。最后面的redis-server /etc/redis/redis.conf相当于替代默认启动命令让Redis启动时加载挂载进去的配置文件。3.3 配置文件至少要包含哪些项我刚跑第一个Redis容器时配置文件只写了个空文件挂载进去结果Redis直接启动失败。原因很简单空的配置文件里没有设置daemonize。Redis的默认启动方式是前台运行但这在Docker里反而是正确的因为Docker容器必须有且仅有一个前台进程Redis自己在容器里做后台守护daemonize yes反而会让容器认为进程已结束而退出。一份够用的最小配置长这样bind 0.0.0.0 protected-mode yes port 6379 requirepass your-strong-password dir /data appendonly yes appendfsync everysec maxmemory 512mb maxmemory-policy allkeys-lru其中bind 0.0.0.0加上protected-mode yes的组合要理解一下Redis默认只监听127.0.0.1但容器里Redis是隔离的外面想访问必须靠端口映射所以要把bind放出来protected-mode会在没有密码的情况下拒绝外部访问于是配合requirepass解决安全认证两者缺一不可。maxmemory和maxmemory-policy是拿Redis当缓存用时最重要的两项配置。maxmemory设一个上限避免Redis把宿主机内存吃光。allkeys-lru表示内存满了以后淘汰最久没被访问的key这是最常见的缓存淘汰策略。如果改成volatile-lru则只淘汰设置了过期时间的key适合那些既要缓存又要保留部分长期数据的场景。配置写好之后把宿主机这个文件挂载进容器重启容器让配置生效docker restart redis-server docker logs redis-server确认日志里出现Ready to accept connections tcp说明Redis已经跑起来。3.4 验证服务是否正常连进去用自带的redis-cli测一下docker exec -it redis-server redis-cli -a your-strong-password ping输出PONG即正常。这里加-a传密码的时候命令行会打出警告说密码暴露在命令行里实际生产环境建议用REDISCLI_AUTH环境变量或者干脆先进容器再执行redis-cli然后通过AUTH命令认证。4. Redis容器日常运维日志、常用命令与网络访问4.1 用docker logs快速定位启动失败Redis容器起不来的时候第一件事永远是看日志最直接的做法docker logs redis-server日志能反映出大量信息。比如配置文件语法错误时会有类似Bad directive or wrong number of arguments的行目录权限不对时会有Cant open the log file: Permission denied端口被占用时则会出现Could not create server TCP listening socket *:6379: bind: Address already in use。如果日志量比较大可以加--tail参数只看尾部几十行docker logs --tail 50 redis-server只看最近50条通常问题就集中在这里。开发环境排错时这个命令的频率远高于别的。4.2 进容器执行redis-cli的几种姿势日常开发中我经常需要直接查看某个key的过期时间、统计某个前缀的key数量、或者给某个key设置值。标准做法就一条命令docker exec -it redis-server redis-cli -a your-strong-password keys *user*docker exec就是进入正在运行的容器执行命令-it表示交互式终端。后面的参数组合等效于在容器内部打开一个Redis客户端并执行命令。如果不想每次带密码可以先进Redis客户端再认证docker exec -it redis-server redis-cli 127.0.0.1:6379 AUTH your-strong-password 127.0.0.1:6379 INFO memoryINFO命令能看到内存使用、连接数、命中率这些关键指标是排查缓存问题的第一工具。4.3 宿主机如何直接访问容器内的Redis有了-p 6379:6379的端口映射宿主机上装一个redis-cli就能直接连redis-cli -h 127.0.0.1 -p 6379 -a your-strong-password如果是跨机器访问则把-h改成宿主机IP局域网内需确保安全组/防火墙放行6379端口。这里要留意Redis这种无加密引擎的中间件不适合直接裸暴露公网要么用云安全组限制来源IP要么干脆只在内网使用。之前我见过有人图省事把Redis的6379端口映射到公网服务器上且没设密码不到一天就被扫描器种了挖矿木马教训非常深刻。4.4 容器重启与删除时如何保住数据容器的生命周期管理和数据保活是我认为Docker跑Redis最核心的优势场景。重启Redis最常见的方式docker restart redis-server如果因为配置变更或者版本升级需要换一个新容器那就docker stop redis-server docker rm redis-server docker run -d \ --name redis-server \ -p 6379:6379 \ -v /Users/you/docker/redis/data:/data \ -v /Users/you/docker/redis/conf/redis.conf:/etc/redis/redis.conf \ --restart unless-stopped \ redis:7.2 \ redis-server /etc/redis/redis.conf只要/data目录还在新容器起来后AOF或RDB文件会自动重放数据完好无损。这套数据在宿主、状态在容器的设计比传统方式在系统里留下的配置文件、日志文件、pid文件散落一地要干净得多。更换版本更是简单把镜像tag从7.2改成7.4其他不动。5. 进阶场景主从复制、哨兵与分布式锁5.1 用Docker Compose搭建一主两从单机Redis毕竟是单点。开发环境想体验一下Redis主从复制最省事的方式是写一个docker-compose.yml一键拉起一套一主两从。这也是热搜词里docker安装redis主从背后的需求。基本配置如下version: 3.8 services: redis-master: image: redis:7.2 container_name: redis-master command: redis-server --requirepass masterpass --appendonly yes ports: - 6379:6379 volumes: - ./master-data:/data redis-slave1: image: redis:7.2 container_name: redis-slave1 command: redis-server --requirepass masterpass --replicaof redis-master 6379 --masterauth masterpass --appendonly yes ports: - 6380:6379 volumes: - ./slave1-data:/data depends_on: - redis-master redis-slave2: image: redis:7.2 container_name: redis-slave2 command: redis-server --requirepass masterpass --replicaof redis-master 6379 --masterauth masterpass --appendonly yes ports: - 6381:6379 volumes: - ./slave2-data:/data depends_on: - redis-master关键点有两个--replicaof redis-master 6379Docker Compose内置DNS会把服务名redis-master解析成对应容器IP所以从节点通过服务名就能找到主节点不需要去查IP。--masterauth masterpass主节点设置了requirepass从节点做全量同步时主节点会要求认证这个参数就是给从节点用的主节点认证密码。启动方式docker compose up -d等大约几秒钟在master容器里执行docker exec -it redis-master redis-cli -a masterpass INFO replication看到role:master且有两个slave0、slave1在线主从链路就通了。再试一下数据的复制方向docker exec -it redis-master redis-cli -a masterpass SET foo bar docker exec -it redis-slave1 redis-cli -a masterpass GET foo正常情况下从节点能读到主节点写入的bar。但从节点默认只读往从节点里写会报错这是Redis的固有设计不是Docker的问题。5.2 主从模式下写失效怎么办互联网上的Redis主从踩坑帖里排名前列的报错大概是这类READONLY You cant write against a read only replica.原因基本可以锁定客户端或者手动执行把写命令发给了从节点。解决办法有三个层面客户端连接配置里指定只连主节点这是最推荐的做法。像Spring Boot的Lettuce连接池配一个主节点的地址就行千万别把从节点写进写操作的连接信息里。如果客户端支持读写分离把读命令路由到从节点、写命令路由到主节点。如果只是手动测试时写错了那就把命令重新发到master节点。开发环境测试主从时我习惯多做一步查看从节点的偏移量是否追上主节点。docker exec -it redis-slave1 redis-cli -a masterpass INFO replication看master_link_status:up和slave_repl_offset值如果偏移量一直增长且和master端持平说明数据同步健康。万一出现master_link_down_since_seconds就去查从节点日志多半是密码不对或者网络不通。5.3 Redis分布式锁在容器化部署下的注意事项热搜词里出现了redis分布式锁这也是后端面试高频题。用Docker部署Redis来做分布式锁很多细节其实和部署方案本身强相关这里挑几个关键点展开讲。分布式锁最经典的实现是SET NX EXSET lock:order:1001 unique-token NX EX 30NX表示只有key不存在时才设置成功EX 30表示30秒后自动过期。但真正生产级的锁实现还要考虑三个问题锁的value必须是唯一标识比如UUID释放锁时要校验value只属于自己防止误删别人刚设置的锁。Redis官方更推荐Redisson客户端它提供的可重入锁、看门狗自动续期机制能在代码层面解决业务没执行完锁就过期的问题。用Docker部署多台Redis做哨兵/集群后分布式锁需要谨慎评估主从切换带来的锁丢失风险。严格场景可以考虑Redlock算法或者类似方案但Redlock本身也有争议很多团队最终选择etcd做强一致锁Redis只承担缓存职责。我个人的观点是Redis做分布式锁是够用但不够绝对安全的折衷方案。如果你的业务场景允许最坏情况下锁的短暂失效比如重复扣减会造成资损那要么上etcd/zk要么至少用Redisson并开启watchdog。不过对学习来说本地用Docker快速起几个Redis实例连成一个主从或者Cluster然后跑通Redisson分布锁的代码这个实验链路能非常直观地帮你理解锁的实现原理。我在本地就是这么干的比看十篇原理文章都来得实在。6. 可视化工具连接Docker里的Redis桌面客户端与连接配置6.1 Redis Desktop Manager还是Another Redis Desktop Manager用命令行的redis-cli操作Redis虽然效率高但看键值列表、查看过期时间、浏览不同db的数据还是图形化工具更直观尤其适合排查数据问题时快速浏览。Redis Desktop ManagerRDM是老牌工具但早期版本需要付费。后来很多开发者转向了Another Redis Desktop ManagerA Redis Desktop Manager的变体开源免费功能上覆盖了日常绝大部分需求。两个工具本质都是Redis GUI客户端连的是同一个协议端口选哪个纯粹看使用习惯和预算。新装环境的话我一般直接推荐Another Redis Desktop Manager下载即用支持Windows/macOS/Linux三端界面比旧版RDM轻量不少。如果你用的是macOS也可以用Homebrew装brew install --cask another-redis-desktop-manager6.2 常见连接失败原因逐一排查用可视化工具连接Docker里的Redis最常见的失败表现是连接超时或者密码错误。按我的经验排查顺序如下确认端口映射。docker ps看容器端口有没有映射出来。如果只有6379/tcp而没有类似0.0.0.0:6379-6379/tcp的映射那就是启动时忘了加-p参数需要重建容器。确认Redis配置。容器里的Redis如果bind的是127.0.0.1映射出来也连不上因为外部流量到达容器时源地址通常不是127.0.0.1。所以前面强调bind 0.0.0.0。确认防火墙。本地连接一般不影响但如果跨机器连接云服务器要在云控制台和系统防火墙两层都放行对应端口。这一步最容易漏。确认密码。注意如果配置文件里设置了requirepass工具里也要填。空密码直连会提示NOAUTH Authentication required。确认TLS。如果Redis启用了TLS但工具里没开TLS选项也会握手失败。本地开发一般不开生产环境另说。排查时用一个curl式的最小测试最有说服力nc -avz 127.0.0.1 6379能看到Connected to就说明TCP层通接下来问题大概率在认证或应用协议层。6.3 开发环境安全提醒别把带密码的6379暴露公网可视化工具连Redis方便归方便但如果你的Redis跑在公网云服务器上端口暴露出去就是引狼入室。我个人的铁律是公网环境绝不直接暴露6379用SSH隧道替代。本地机器通过SSH隧道连远端Docker里的Redisssh -L 6379:127.0.0.1:6379 useryour-server-ip这会在本地开一个6379端口和服务器上的Redis之间搭一条加密隧道然后工具连127.0.0.1:6379就和连服务器上的Redis等效了。既安全又不用改Docker配置。同理访问服务器上Docker里其他MySQL、MongoDB等中间件也能这样操作这也是为什么我在服务器上装Docker后基本很少额外暴露管理端口给公网。7. Redis缓存治理与常见坑从Docker视角看缓存问题7.1 内存暴涨maxmemory和淘汰策略是保命符缓存治理的基础是内存治理。如果把Redis当缓存无脑往里塞又不管容量上限很快就会出现两种情况要么宿主机内存被打爆系统开始swapDocker和其他容器跟着遭殃要么Redis因为内存分配失败直接崩掉。我在配置Redis容器的第一件事就是按当前机器内存的1/4到1/2设maxmemory。比如机器有8G内存就设maxmemory 2gb同时配合maxmemory-policy allkeys-lru。这样即使某个业务方写入了大量无用keyRedis也不会把整个宿主机拖垮。检查命中率是缓存治理最直观的指标docker exec -it redis-server redis-cli -a your-password INFO stats看keyspace_hits和keyspace_misses两个数值。命中率长期低于80%通常意味着被缓存的key访问频率差异太大或者缓存粒度设计不合理。这时候不是加内存的问题而是该查业务代码里缓存的key设计。7.2 缓存穿透、击穿、雪崩在容器化场景下的表现用Docker部署Redis缓存穿透、击穿、雪崩这三个问题并不会因为容器化而消失反而有个特点容器重启在早期是比较频繁的这天然会放大缓存雪崩的概率。穿透查询一个不存在的keyRedis里没有请求打到底层数据库。容器化部署时如果服务A、B、C共享一个Redis某个服务代码写死了一个不存在的key频繁查询会把Redis这块公共资源拖慢其他服务跟着遭殃。击穿某个热点key过期瞬间大量请求同时杀向数据库。分布式锁在这里就有了新用途——重建缓存的代码加上锁让只有一个请求去查库回填缓存其余请求先等待或者直接返回旧值。雪崩大量key在同一时间过期请求洪峰打到数据库。容器化部署下如果重启Docker时没等Redis恢复就放开流量也会造成类似的集中冲击。建议错开key的过期时间比如SET value EX 300 随机数。排查时大部分问题都围绕key的过期时间、缓存回填代码的并发控制、以及降级策略展开。Docker本身不背锅但你通过重启容器来重启大法解决一切问题的时候缓存清空带来的瞬时数据库压力是需要提前评估的。7.3 序列化与Lettuce超时问题两个高频报错的现场还原开发日常里有两个报错几乎每个人都有机会遇到。第一个是Redis key的value序列化格式不可读。用Spring Boot的RedisTemplate时如果不指定Jackson序列化器默认存进去的可能是二进制序列化数据在可视化工具里看是一串\xAC\xED开头的乱码。这类问题的根源和Redis本身无关而是客户端序列化策略没配好。建议统一使用StringRedisSerializer存keyJackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer存value这样既能排查问题又不会被乱码劝退。第二个是Lettuce客户端的那句经典报错RedisCommandTimeoutException: Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException这个报错出现时第一反应别去调大超时时间就完事。它的根因场景通常包括Redis容器所在机器负载过高、网络延迟抖动、或者Lettuce的连接池里堆满了超时命令。排查方式docker stats redis-server看CPU和内存占用率如果Redis容器本身CPU一直很高那就要检查是否有很多慢查询或者大key操作。如果容器很空闲但客户端超时查一下宿主机网络尤其在使用Docker Desktop的Windows环境偶尔会有虚拟网卡性能问题把Lettuce的clientName设置好、连接池调大一点也能缓解一部分。7.4 日志排查查看Docker里Redis的慢查询Redis的慢查询日志也是排查缓存问题的利器。默认情况下超过100毫秒的命令会被记录下来但开发环境可以调小阈值方便抓问题docker exec -it redis-server redis-cli -a your-password CONFIG SET slowlog-log-slower-than 10000单位是微秒10000微秒即10毫秒。然后查看慢日志docker exec -it redis-server redis-cli -a your-password SLOWLOG GET 10慢日志能告诉我们哪些命令耗时过长常见原因包括用了KEYS *这种全库扫描、某个超大的hash操作、或者RDB持久化fork子进程导致阻塞。结合时间戳去对业务请求日志很容易锁定是哪个接口在拖后腿。如果是持久化引起的fork阻塞可以把stop-writes-on-bgsave-error no这种配置谨慎开启或者调大rdb-save-incremental-fsync优化fork期间的IO压力。不过生产环境的持久化策略需要审慎评估RDB和AOF各有取舍这里就不展开细说但要记住Docker里配置持久化与否、用AOF还是RDB和使用传统方式部署逻辑相同除了daemonize必须为no之外其余完全可以复用你的既有Redis配置。8. 环境变量与Compose实战把Redis配置固化下来8.1 一条命令起一个带密码和持久化的Redis前面已经给了完整的docker run版本。为方便复制这里再给一个精简版docker run -d --name redis-dev \ -p 6379:6379 \ -v $PWD/redis.conf:/etc/redis/redis.conf \ -v $PWD/data:/data \ --restart always \ redis:7.2 \ redis-server /etc/redis/redis.conf$PWD表示当前目录这样在哪个目录执行数据就落在哪个目录的data子目录下。做开发测试时每个项目单独一个redis数据目录互不污染。要清空这个Redis的数据直接把这个data目录拷走或者删除即可不需要动容器以外的任何东西。8.2 docker-compose.yml模板一键起Redis可视化面板如果开发机上需要一套Redis 可视化的完整环境或者想给团队其他成员一键复现用docker compose更清晰。下面这个模板我用了很久version: 3.8 services: redis: image: redis:7.2 container_name: redis-comp restart: always command: redis-server --requirepass devpassword --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru ports: - 6379:6379 volumes: - ./redis-data:/data redis-commander: image: rediscommander/redis-commander:latest container_name: redis-commander restart: always environment: REDIS_HOSTS: local:redis:6379:0:devpassword ports: - 8081:8081 depends_on: - redis启动docker compose up -d然后浏览器打开http://localhost:8081就能看到Redis里所有key的实时列表、内存状况、客户端连接。虽然是老项目但胜在零配置、轻量个人开发足够用了。如果喜欢桌面工具用Another Redis Desktop Manager连127.0.0.1:6379也一样。两条路殊途同归选自己顺手的。8.3 配置与代码分开Redis配置的版本管理思路最后一个想说的点Redis的配置尽量写到配置文件里而不是全都塞进--requirepass这种命令参数。原因很简单只有配置文件可以放进Git仓库做版本管理。我习惯在工作目录里建一个redis/conf子目录redis.conf丢进去提交时和代码一起走版本控制。这样换了新环境拉一下代码docker compose up -dRedis环境和线上配置完全一致。我自己由于经历过太多次本机Redis和测试环境不一致的坑深知这种固化配置方式能省多少事。不管是密码策略、appendonly持久化开关、还是maxmemory值全部统一由配置文件管理交付时的描述就一句话容器配置以conf目录下的redis.conf为准。退一步说就算你现在只是想在本地跑个Redis测试某个命令用Docker也比在本机装一个Redis服务来得干净。用完了docker stop redis-server6379端口立即释放系统目录里不会残留任何默认配置或者数据垃圾。这种清爽感用过一次就回不去了。9. 我个人在Docker部署Redis过程中的几点最深体会最后以个人的实操体会收个尾不写虚的。第一版本锁定是保命。无论redis:latest还是docker pull时不写标签总有一天会被新版本坑到。Redis自身迭代快行为变化多常年跑生产环境的人对版本非常敏感。一句话建议任何环境下都写死主版本和次版本例如redis:7.2。第二数据目录的挂载位置要提前规划。不建议随便挂在某个临时路径更不要用容器匿名卷。给每个环境的Redis规划好固定目录比如/opt/redis-data/{env}配合--name命名规范将来排查问题、备份数据都会顺畅很多。第三配置文件挂载之后改配置绝不直接改容器内的文件。容器内的文件是临时的一删容器就没了。宿主机的挂载文件才是源头。每次改完配置docker restart redis-server然后一定用docker logs确认启动没有报错。覆盖配置前建议先备份一个.bak哪怕只是一个字符的改动。第四Redis版本升级不要原地升级。先拉新镜像起一个新容器把旧容器的/data目录复制过来测试通过后再切换流量。用Docker的优势在这儿体现得淋漓尽致每次升级都是全新的运行时环境不会把旧的编译残留、旧动态库带进新版本里。如果你正准备在Docker上部署Redis我的终极建议是别跳过配置文件和数据目录的挂载别忽略密码设置和防火墙别把生产环境的关键数据留在一个没有--restart策略的容器里。把这几条底线守住Docker会给你的Redis管理带来远超预期的顺畅体验。