先说一个很多人问过我的问题为什么非要用 Docker 来装 Redis原因其实很简单——本地开发机想快速起一个 Redis 环境手动下载编译安装要处理一堆依赖跨平台还有各种坑而 Docker 把整个 Redis 运行环境打包成了镜像一条命令就能跑起来换机器也是同样的命令版本想换就换。更重要的是生产环境里 Redis 很少是单机独舞主从复制、哨兵高可用、集群分片这些复杂拓扑用 Docker Compose 编排远比手工在几台机器上折腾要清晰、可控得多。这篇文章我会从最基础的拉镜像、起容器讲起到配置文件挂载、数据持久化再到用 Docker Compose 搭建主从加哨兵最后把可视化客户端和常见问题排查一起整理了全是实际跑过的步骤和踩过的坑。1. 装前准备Docker 和 Redis 的基础认知1.1 为什么推荐用 Docker 跑 Redis先把概念捋清楚。Docker 镜像可以理解成一个只读的模板里面已经装好了 Redis 的二进制、默认配置和运行环境容器则是这个模板运行起来后的实例有独立的文件系统、网络和进程空间。用生活里的例子来说镜像就像是预制菜包容器是你在锅里炒出来的那盘菜同一个菜包可以炒出无数盘菜互不干扰。用这种方式跑 Redis最大的好处有三个环境隔离干净Redis 不会污染宿主机的文件系统卸载就是删容器删镜像不会留下一堆残留文件和配置。版本切换成本极低需要从 Redis 6 升到 Redis 7改一下镜像标签重新起容器就行不用去官网下载、编译、卸载旧版实测省下的时间不是一星半点。拓扑编排方便主从、哨兵、集群这些多节点架构用 docker-compose.yml 一次定义好一条docker compose up -d全部拉起比在几台机器上手工配置省太多事。当然也有需要注意的地方。Docker 本身有一层网络地址转换极端高并发的场景下会有轻微性能损耗。如果对性能有极致要求生产环境也可以考虑直接物理机装 Redis但开发测试环境、中低并发业务、或者团队统一管理版本的场景Docker 几乎是最优解。我个人的建议是开发环境无脑用 Docker生产环境看具体性能指标再定。1.2 宿主环境选择与 Docker 安装要点装之前先确认你的操作系统。Windows 和 macOS 通常用 Docker DesktopLinux 直接用 Docker Engine。这里我不展开完整的安装教程因为不同系统差异很大只强调几个关键点。Windows 用户注意Docker Desktop 依赖 WSL2 和 Windows 虚拟化功能。安装前在“控制面板-程序-启用或关闭 Windows 功能”里确认“适用于 Linux 的 Windows 子系统”和“虚拟机平台”都已勾选。很多人碰到virtualization support not detected或者Docker Desktop failed to start这类报错十有八九是 BIOS 里的 VT-x/AMD-V 没开或者 Hyper-V、WSL2 没装全。装完之后在命令行敲wsl --status看一下 WSL 内核版本太旧了也要更新。Linux 用户注意CentOS 和 Ubuntu 的安装命令不一样但装完后都有一个必做动作——把当前用户加入 docker 组不然每次都要 sudo 前缀麻烦得要死。sudo usermod -aG docker $USER改完记得注销重新登录否则组权限不生效。这个动作虽然简单但很多人忽略导致后边每个 docker 命令都报 permission denied排查半天其实是这个问题。装完验证一下 Docker 是否正常docker version docker run hello-world能正常打印版本信息和 hello-world 的提示说明 Docker 环境没问题了。接下来就可以正式进入 Redis 部署环节。2. 快速部署从拉镜像到跑通第一个 Redis 实例2.1 拉取镜像与最简启动先拉镜像。Redis 官方镜像都在 Docker Hub 的 redis 仓库下直接指定版本标签别用 latest 打生产这是铁律docker pull redis:7.2版本号可以按需选7.x 是目前的主流稳定版6.2 也有不少存量项目在用。拉下来后确认一下docker images | grep redis输出里能看到redis 7.2 ...这样的行说明镜像已经就位。最简启动方式其实就一条命令docker run -d --name my-redis -p 6379:6379 redis:7.2拆开解释一下每个参数-d后台运行容器。--name my-redis给容器起个名字之后操作直接叫名字不用记容器 ID。-p 6379:6379把宿主机的 6379 端口映射到容器的 6379 端口。冒号左边是宿主机端口右边是容器内端口。redis:7.2使用的镜像名加标签。跑起来之后验证一下docker ps redis-cli -h 127.0.0.1 -p 6379 ping如果返回PONG说明 Redis 已经活着了。这条最简命令适合临时验证但有一个致命问题容器一删数据全没了配置也无法定制。所以实际使用必须做配置挂载和持久化见下一节。2.2 挂载配置文件和数据目录配置和数据这两件事都是在docker run时通过-v参数把宿主机目录挂载进容器里。先看完整命令mkdir -p /usr/local/redis/conf /usr/local/redis/data docker run -d \ --name my-redis \ -p 6379:6379 \ -v /usr/local/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /usr/local/redis/data:/data \ redis:7.2 \ redis-server /etc/redis/redis.conf这里有两个关键点需要说明。第一配置文件的路径和启动命令。官方镜像里 Redis 默认的配置路径是/usr/local/etc/redis/redis.conf但我习惯挂到/etc/redis/redis.conf然后把启动命令显式写成redis-server /etc/redis/redis.conf这样配置路径一目了然不容易出错。需要注意的是如果不把配置文件挂进去容器会以 Redis 的默认配置启动日志里会有Warning: no config file specified, using the default config的提示这时候你改不了密码、改不了持久化策略出错率很高。第二数据目录挂载。Redis 的持久化文件RDB 快照和 AOF 日志默认写在/data目录这也是官方镜像里WORKDIR指定的工作目录。把宿主机目录挂到/data就算容器删了重建数据还在宿主机上新容器一挂上来就能继续用。这个习惯一定要养成否则容器被误删或者升级重建的时候Redis 里缓存的数据全部归零如果是缓存数据库还好如果是存了业务状态的那就是事故了。在这里顺便提一下redis.conf的权限问题。宿主机挂载进容器的文件容器内进程如果要以非 root 身份运行可能出现权限不足读取不了配置的情况。官方镜像默认以 root 启动开发环境问题不大生产环境要关注一下。2.3 常用参数选型与配置解析关于配置文件我不建议从官方提供的完整 redis.conf 直接抄那文件 2000 多行很多配置用不上反而容易看花眼。实际生产里我常用的最小配置集大概是这样的# 不以后台守护进程方式运行让 redis-server 以前台方式跑在容器里 daemonize no # 数据目录持久化文件都放这里 dir /data # 开启 AOF 持久化 appendonly yes # AOF 刷盘策略每秒一次兼顾性能和安全 appendfsync everysec # 监听所有网卡地址容器内 IP 不受限 bind 0.0.0.0 # 访问密码 requirepass 你的密码 # 保护模式关闭否则 bind 之外的外部连接会被拒绝 protected-mode no # RDB 快照规则默认策略即可可自定义 save 900 1 save 300 10 save 60 10000逐条说一下背后的逻辑。daemonize no是容器场景里特别容易忽略的配置。Redis 默认配置里 daemonize 可能是 no但如果改成 yesRedis 会 fork 出一个后台进程容器里的前台进程直接退出Docker 会认为容器启动失败直接把它停掉。正确做法是在容器场景里始终保持前台运行。appendonly yes决定是否开启 AOF 持久化。Redis 有两种持久化方式RDB 是定期全量快照恢复快但可能在两次快照之间丢数据AOF 是记录每一条写操作的日志配合everysec刷盘策略最多丢一秒的数据。对绝大多数业务来说AOF 是必开的RDB 可以保留作为快速恢复的兜底。bind 0.0.0.0和protected-mode no是容器通信里的常见坑。Docker 默认的网络模式下容器有一个独立的 IP宿主机通过端口映射访问它。如果 Redis 的 bind 只写127.0.0.1那容器内部只能本机访问宿主机连不进去而 Redis 的 protected-mode 默认开启时非本机连接会被拒绝除非配置了密码。所以最简单的组合是 bind 监听所有网卡、protected-mode 关掉、再通过requirepass设置强密码来保障安全。requirepass自己设一个强密码别用123456这种。连接命令要带上密码redis-cli -h 127.0.0.1 -p 6379 -a 你的密码 ping配置写好后重启容器让配置生效docker restart my-redis再通过docker logs my-redis查看启动日志确认没有报错配置就生效了。到这里一个带密码、带持久化、可挂载配置的 Redis 单点实例就部署完成了。但实际项目里单点往往不够接下来进入到更实用的部分用 Docker Compose 编排多节点。3. 进阶实战用 Docker Compose 搭建主从和哨兵3.1 Compose 编排单节点的结构设计Docker Compose 是 Docker 官方的多容器编排工具用 YAML 文件定义一组服务一键启停。相比一条条写docker runCompose 的优势很明显配置写进文件版本化管理团队成员拉下来直接docker compose up -d就能复现一整套环境。Compose 文件的核心结构是三个层级services定义服务、networks定义网络、volumes定义数据卷。结合 Redis 的场景一个单节点的 Compose 文件长这样version: 3.8 services: redis: image: redis:7.2 container_name: my-redis restart: always ports: - 6379:6379 volumes: - ./conf/redis.conf:/etc/redis/redis.conf - redis-data:/data command: [redis-server, /etc/redis/redis.conf] networks: - redis-net volumes: redis-data: networks: redis-net: driver: bridge几个设计要点说下。restart: always很关键容器异常退出或 Docker 服务重启后会自动拉起 Redis 容器减少人工干预。网络这里我用的是自定义 bridge 网络redis-net。默认的 bridge 网络也能用但自定义网络的好处是容器间可以通过服务名直接解析 IP比如主从配置里写replicaof master 6379Compose 会自动把master解析成主节点容器的 IP。不用手动查 IP也不用--link这种老掉牙的做法这会让后续的配置和扩展舒服很多。数据卷redis-data是 Docker 管理的卷比直接挂载宿主机目录更规范备份迁移都方便。如果偏好宿主机目录也可以改成./data:/data。写完文件后启动docker compose up -d查看状态docker compose ps有一个细节提醒Compose 文件里的version字段在新版 Docker 里已经标记为废弃可以写也可以不写写了也不影响运行。不用纠结这个部分老教程里强调必须写 3.8 之类版本号新版 Comose 插件已经忽略它了。3.2 主从复制配置与验证现在升级一下需求。项目里缓存读多写少想把读的压力分摊出去或者担心单点故障就需要部署一主一从甚至一主多从。Redis 的主从复制逻辑不复杂从节点连接主节点主节点把全量数据发给从节点之后持续同步增量写操作。用 Compose 部署一主两从目录结构这样安排redis-stack/ ├── docker-compose.yml ├── master/ │ └── redis.conf ├── slave1/ │ └── redis.conf └── slave2/ │ └── redis.confcompose 文件关键部分如下services: master: image: redis:7.2 container_name: redis-master ports: - 6379:6379 volumes: - ./master/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] networks: - redis-net slave1: image: redis:7.2 container_name: redis-slave1 ports: - 6380:6379 volumes: - ./slave1/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] depends_on: - master networks: - redis-net slave2: image: redis:7.2 container_name: redis-slave2 ports: - 6381:6379 volumes: - ./slave2/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] depends_on: - master networks: - redis-net主节点的 redis.conf 沿用前面单节点的配置从节点的 redis.conf 关键增加一行replicaof master 6379因为 Compose 网络里服务名master就是主节点的 DNS 名称Redis 会自动解析。这里注意要写 6379因为从节点连的是主节点容器内的端口而不是宿主机映射的端口。主从节点都必须设置相同的requirepass。另外需要在从节点的配置里加上masterauth 你的密码这句很重要主节点开密码后从节点复制数据时要提供密码才能通过认证很多初次配主从的人忘了加这一行结果主从关系一直起不来日志里报MASTER - REPLICA sync started然后反复Connection error on master。启动后验证主从状态docker exec -it redis-master redis-cli -a 你的密码 info replication重点关注输出里的几项role:master connected_slaves:2 slave0:ip172.x.x.x,port6379,stateonline slave1:ip172.x.x.x,port6379,stateonline再进入从节点验证docker exec -it redis-slave1 redis-cli -a 你的密码 info replication输出里role:slave加master_link_status:up就代表复制链路是通的。有一个容易让人迷惑的点端口映射。我让主从容器的宿主机端口分别是 6379、6380、6381但容器内部 Redis 都是 6379。之所以这样映射是因为从节点配置里写replicaof master 6379这个 6379 是容器内端口跟宿主机端口没关系。很多新手在这里想不通总以为要写成映射后的端口实际上不需要。3.3 哨兵模式实现高可用主从能解决读扩展问题但解决不了一个痛点主节点挂了从节点不会自动升级成主节点整个写服务就断了。哨兵Sentinel模式就是来解决这个问题的它监控主节点状态发现主节点不可用后自动在从节点里选出一个新的主节点实现故障转移。用 Compose 加三个哨兵容器文件结构变成redis-stack/ ├── docker-compose.yml ├── master/redis.conf ├── slave1/redis.conf ├── slave2/redis.conf └── sentinel/ └── sentinel.conf哨兵的配置比较精简port 26379 dir /tmp sentinel monitor mymaster master 6379 2 sentinel auth-pass mymaster 你的密码 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000 sentinel parallel-syncs mymaster 1解释几个参数sentinel monitor mymaster master 6379 2监控名为 mymaster 的主节点地址是masterCompose 服务名端口 63792表示至少 2 个哨兵同意主节点挂了才触发故障转移。sentinel auth-pass mymaster 你的密码主节点开了 requirepass哨兵必须带密码才能通信。down-after-milliseconds判定主节点主观下线的时间这里设 5 秒。parallel-syncs故障转移后同时允许几个新从节点去做全量复制设 1 防止瞬时压力过大。Compose 里加哨兵服务sentinel1: image: redis:7.2 container_name: redis-sentinel1 ports: - 26379:26379 volumes: - ./sentinel/sentinel.conf:/etc/redis/sentinel.conf command: [redis-server, /etc/redis/sentinel.conf, --sentinel] depends_on: - master networks: - redis-net注意启动命令后面一定要跟--sentinel否则 Redis 会把它当普通服务启动端口行为都不对。哨兵一般部署奇数个比如 3 个因为投票需要多数同意才能故障转移2 个哨兵如果其中一个挂了就投不出结果了。实际生产我会部署 3 个哨兵容器分散到不同宿主机上这篇文章里演示的时候一个 Compose 文件内部署 3 个哨兵服务容器名分别是 sentinel1、sentinel2、sentinel3配置相同即可。验证哨兵是否工作docker exec -it redis-sentinel1 redis-cli -p 26379 sentinel master mymaster输出里能看到主节点的 IP、端口和状态信息。这里有一个比较有意思的细节输出里主节点地址会是172.x.x.x这样的容器网络 IP而不是宿主机的 IP因为哨兵是通过 Compose 网络连接 Redis 的。如果你在宿主机上用客户端连接哨兵需要连哨兵的宿主机映射端口26379再通过sentinel get-master-addr-by-name mymaster命令问出当前主节点在容器网络里的地址然后你还需要用宿主机映射的 6379 端口去连接这在生产环境里需要一个额外的服务发现环节开发环境验证的话知道这个映射关系就行不用过度纠结。手动做一次故障转移演练docker stop redis-master等待几秒后查看某个哨兵的日志docker logs redis-sentinel1 --tail 50日志里会出现switch-master相关的记录说明哨兵已经选出了新的主节点。再查看新主节点状态docker exec -it redis-slave1 redis-cli -a 你的密码 info replication如果输出role:master说明自动故障转移成功了。这个演练我建议每个团队都做一次不然真出事故的时候心里没底。4. 可视化客户端与日常运维排查4.1 客户端工具选型容器跑起来了命令行验证过了但日常开发里不可能总是敲命令。选择一个好用的可视化客户端能明显提升效率。市面上常见的几个工具我按实际使用体验对比一下工具跨平台免费程度特点Redis Desktop Manager是付费/旧版免费老牌工具新版收费免费版阉割较多Another Redis Desktop Manager是开源免费目前最推荐UI 现代化功能完善RedisInsight是官方免费Redis 官方出品自带内存分析适合专业调优TablePlus是部分免费数据库全家桶Redis 只是其中一项个人最常用的是 Another Redis Desktop ManagerGitHub 上直接搜就能找到开源免费支持 key 的树形浏览、命令行交互、慢日志查看、集群模式功能覆盖日常开发完全足够。连接的时候填宿主机 IP、映射端口和 requirepass 密码就行不需要额外配置。RedisInsight 我也装了它的内存分析功能很强大可以直观看到哪些 key 占内存最多、哪些大 key 拖慢性能排查线上问题的时候帮助很大。缺点是界面比 ARDM 重一些不适合经常开开关关的轻量使用。一个小提醒不管用哪个客户端连接 Redis 都建议先确认访问的安全性尤其是 Redis 绑定了0.0.0.0且没有密码的情况下公网环境可能被扫描器直接打进来。生产环境 Redis 端口不要暴露到公网内网访问也要通过安全组或防火墙限制来源 IP。4.2 常见问题与排查速查表把 docker 装 redis 过程中最常见的坑整理成一个速查表每个都是实战中真实遇到过的问题现象原因解决办法容器启动秒退配置里daemonize yes改成daemonize no前台运行宿主机连不上 Redisbind只绑了 127.0.0.1改成bind 0.0.0.0外部连接被拒绝protected-mode yes未关关闭保护模式或配置密码主从同步失败从节点未配masterauth从节点配置中加masterauth 密码容器重启后数据丢失没挂载数据目录把/data挂到宿主机或数据卷密码认证失败客户端命令没用-a连接时带密码参数docker compose命令不存在老版本没有 compose 插件装 docker-compose-plugin 或用docker-composeDocker Desktop 启动失败虚拟化未启用或 WSL2 异常检查 BIOS 虚拟化、WSL2 更新除了表格里的内容再展开讲两个容易误判的问题。第一个是 “Connection refused” 并不一定是 Redis 问题。我在实际排障时发现很多人一看到Connection refused就以为是 Redis 里面的配置问题结果查了半天下载日志。应该先确认几件事容器有没有起来docker ps里状态是 Up 还是 Exited端口映射有没有生效docker port myredis输出映射对不对宿主机防火墙有没有拦 6379 端口。把这几个排查完再去翻 Redis 日志。排障的顺序很重要先外后内先容器后应用能省大量时间。第二个是日志定位技巧。容器内 Redis 出问题第一件事必然是看日志docker logs my-redis docker logs --tail 100 my-redis如果日志信息不够还可以进入容器看完整日志文件。注意容器里 Redis 日志默认打到 stdout所以docker logs就能看到不用去容器里翻日志文件。这是 Docker 场景和物理机安装的一点区别物理机 Redis 日志写在文件里容器里则直接输出到标准输出。4.3 用容器内 redis-cli 做日常调试命令行虽然不如 GUI 直观但排障的时候比任何客户端都好使因为它在容器内直接执行不经过网络层能快速区分问题是不是出在网络或客户端配置上。进入容器执行命令docker exec -it my-redis /bin/bash redis-cli -a 你的密码或者不进入容器直接在宿主机上执行docker exec -it my-redis redis-cli -a 你的密码 ping docker exec -it my-redis redis-cli --raw keys user:*几个实用的调试命令# 查看所有 key--stat 可以实时监控 docker exec -it my-redis redis-cli -a 密码 --stat # 查看内存和 key 数量 docker exec -it my-redis redis-cli -a 密码 info keyspace docker exec -it my-redis redis-cli -a 密码 info memory # 查看慢日志排查慢查询很有用 docker exec -it my-redis redis-cli -a 密码 slowlog get 10 # 查看大 key扫描分析 docker exec -it my-redis redis-cli -a 密码 --bigkeys--bigkeys这个命令我强烈推荐定期跑一下Redis 里如果有特别大的 key比如一个几兆的字符串或者一个几万元素的 list会拖慢整个实例的性能。它会扫描整个实例并按类型统计最大 key扫完可以看到哪类数据有问题。这也是 RedisInsight 内存分析能做的但命令行版更方便快速定位。调试完记得退出容器exit就行。还有一个细节进入容器后再退出容器并不会让容器停止因为-it只是附加到容器的终端不影响主进程运行。5. 日常运维习惯与经验积累5.1 备份和恢复的正确姿势很多人以为 Redis 数据都在内存里不需要备份这是很大的误区。Redis 的持久化文件在/data目录下RDB 文件是dump.rdbAOF 文件是appendonly.aof。备份方式有两种一种直接拷贝持久化文件另一种用BGSAVE命令在线生成快照再拷贝。在 Docker 场景下我的习惯是直接对挂载的数据目录做文件级备份# 先触发一次 BGSAVE确保数据是最新的 docker exec -it my-redis redis-cli -a 密码 BGSAVE # 再备份数据目录 cp -r /usr/local/redis/data /backup/redis-20240101恢复时把备份的文件放回挂载目录重新启动容器即可。这里要特别提醒备份 AOF 文件前如果 AOF 正在写入直接拷贝可能出现文件不一致。稳妥的做法是先执行BGSAVE生成一份 RDB 快照然后备份 RDB 文件或者通过config get appendonly确认状态后短暂停写再拷贝避免文件写一半的问题。日常备份我一般用 RDB 文件就够了恢复速度快最多丢最后一次快照到故障之间的数据对大多数缓存场景可以接受。5.2 资源限制和容器健康检查生产环境里容器必须设置资源限制防止某个 Redis 实例把宿主机内存吃光。在docker run时可以加参数Compsoe 里也一样deploy: resources: limits: cpus: 1.0 memory: 1g这样 Redis 容器最多用 1 个 CPU 核心和 1GB 内存超出会触发 OOM而不会拖垮整个宿主机。健康检查也是容易忽略的一点。Redis 容器如果只是进程存活但内部出了问题Docker 依然认为它是健康的。可以在 Compose 里加上健康检查healthcheck: test: [CMD, redis-cli, -a, 密码, ping] interval: 30s timeout: 5s retries: 3redis-cli ping能返回 PONG 说明 Redis 正常响应否则 Docker 会标记容器为 unhealthy。这个状态可以配合监控系统做告警也可以配合depends_on条件控制服务启动顺序避免主从同步时从节点比主节点先起来导致连接失败。5.3 我踩过的一些印象深刻的坑最后分享几个比较典型的踩坑实例。第一个是版本升级的教训。有一次我从 Redis 6 升级到 7直接改了镜像标签重新跑容器结果客户端全部连不上查了半天才发现是 Redis 7 默认开启了 ACL 访问控制原来在 Redis 6 里配置的 requirepass 和新的 ACL 体系有冲突。后来老老实实对比了两版配置重新调整了认证方式才好起来。这个教训告诉我升级 Redis 大版本前一定要看官方配置变更说明不要想当然。第二个是端口冲突的坑。同一台宿主机上如果已经装了 MySQL 或者别的服务占用了 6379 端口docker run时会报端口绑定失败。这时候要么换宿主机映射端口比如-p 6380:6379要么把原来的服务停掉。在团队开发环境里我习惯提前规划端口分配表Redis 从 6379 开始递增避免同事之间互相抢端口。第三个是容器时区的坑。Redis 日志和TIME命令默认使用 UTC 时间国内使用时差 8 小时。排查问题看日志的时候总觉得时间对不上。解决方式是在启动容器时挂载时区文件volumes: - /etc/localtime:/etc/localtime:ro这样容器内时间就和宿主机同步了查日志的时候舒服很多。还有一次比较有意思。有人反馈 Redis 连不上怎么查都正常最后发现是 Docker Desktop 的 DNS 解析问题容器内解析宿主机主机名失败。这种问题跟 Redis 本身没关系是 Docker 网络配置的锅。遇到容器内访问不了宿主机服务在容器里用getent hosts host.docker.internal看能不能解析到地址Windows 和 macOS 的 Docker Desktop 通常自动支持这个特殊域名Linux 下的 Docker Engine 需要加extra_hosts配置才能用。5.4 关于 Redis 数据类型的几句额外分享既然装好了 Redis免不了要存数据。Redis 不止有简单的字符串缓存五种基本数据类型用好了能省下大量业务代码。我简单整理一下方便刚开始接触 Redis 的朋友String最常用的键值对缓存、计数器、分布式锁都能用它。Hash适合存储对象用户信息、商品详情可以单独修改某个字段比序列化整个对象效率高。List双向链表可以做消息队列、时间线、最新列表。Set去重集合适合做标签、关注关系、共同好友这类场景。ZSet有序集合排行榜、优先队列的标配带分数排序是它的核心能力。如果你用 Docker 只是搭个缓存服务String 可能够用但如果你准备用自己的 Redis 做更复杂的业务建议把 Hash 和 ZSet 的常用命令过一遍这两个在真实业务里利用率非常高。比如 ZSet 做排行榜一条ZREVRANGE就能拿前 N 名比在 MySQL 里排序再缓存简单太多了。拿同样的思路处理分布式锁的场景。网上能搜到不少 Redis 分布式锁的例子其实核心就几条命令SET key randomValue NX EX seconds加锁Lua 脚本判断 value 一致后 DEL 解锁。Docker 部署的 Redis 用来做分布式锁完全没问题需要注意的就是选主从架构时不要在主节点上加锁后在从节点上丢失了生产场景要考虑 RedLock 或者直接纯单机锁这里不展开但方向先给到。这些数据类型的技巧多说一句不是 Docker 特有的而是 Redis 本身的能力。用 Docker 把 Redis 跑起来后你获得的是一个完整能力的 Redis不要只把它当成一个能存 key-value 的黑盒子。个人在实际操作中的体会是Docker 装 Redis 这件事本身不难难的是把环境理解透、把配置目的搞清楚、把灾备意识和网络模型建立起来。一条docker run命令背后藏着端口映射、数据持久化、网络通信、认证安全几个维度的知识每一样都在生产环境里出过真实的事故。把基本功打牢后面不管是用 Compose 编排多节点还是接集群模式都会顺很多。最后再分享一个小技巧。如果你经常在多个项目里切换每个项目依赖不同版本的 Redis建议在宿主机上建一个固定的目录结构每个版本一套配置文件再写一个简单的 shell 脚本封装启动命令比如#!/bin/bash # 启动 Redis 6.2 docker run -d --name redis-6 \ -v ~/docker/redis/6.2/conf:/etc/redis \ -v ~/docker/redis/6.2/data:/data \ -p 6379:6379 redis:6.2 redis-server /etc/redis/redis.conf这样切项目的时候就是执行一个脚本的事不用每次翻文档回忆参数。这个习惯帮我省了太多时间也推荐给你。
先说一个很多人问过我的问题为什么非要用 Docker 来装 Redis原因其实很简单——本地开发机想快速起一个 Redis 环境手动下载编译安装要处理一堆依赖跨平台还有各种坑而 Docker 把整个 Redis 运行环境打包成了镜像一条命令就能跑起来换机器也是同样的命令版本想换就换。更重要的是生产环境里 Redis 很少是单机独舞主从复制、哨兵高可用、集群分片这些复杂拓扑用 Docker Compose 编排远比手工在几台机器上折腾要清晰、可控得多。这篇文章我会从最基础的拉镜像、起容器讲起到配置文件挂载、数据持久化再到用 Docker Compose 搭建主从加哨兵最后把可视化客户端和常见问题排查一起整理了全是实际跑过的步骤和踩过的坑。1. 装前准备Docker 和 Redis 的基础认知1.1 为什么推荐用 Docker 跑 Redis先把概念捋清楚。Docker 镜像可以理解成一个只读的模板里面已经装好了 Redis 的二进制、默认配置和运行环境容器则是这个模板运行起来后的实例有独立的文件系统、网络和进程空间。用生活里的例子来说镜像就像是预制菜包容器是你在锅里炒出来的那盘菜同一个菜包可以炒出无数盘菜互不干扰。用这种方式跑 Redis最大的好处有三个环境隔离干净Redis 不会污染宿主机的文件系统卸载就是删容器删镜像不会留下一堆残留文件和配置。版本切换成本极低需要从 Redis 6 升到 Redis 7改一下镜像标签重新起容器就行不用去官网下载、编译、卸载旧版实测省下的时间不是一星半点。拓扑编排方便主从、哨兵、集群这些多节点架构用 docker-compose.yml 一次定义好一条docker compose up -d全部拉起比在几台机器上手工配置省太多事。当然也有需要注意的地方。Docker 本身有一层网络地址转换极端高并发的场景下会有轻微性能损耗。如果对性能有极致要求生产环境也可以考虑直接物理机装 Redis但开发测试环境、中低并发业务、或者团队统一管理版本的场景Docker 几乎是最优解。我个人的建议是开发环境无脑用 Docker生产环境看具体性能指标再定。1.2 宿主环境选择与 Docker 安装要点装之前先确认你的操作系统。Windows 和 macOS 通常用 Docker DesktopLinux 直接用 Docker Engine。这里我不展开完整的安装教程因为不同系统差异很大只强调几个关键点。Windows 用户注意Docker Desktop 依赖 WSL2 和 Windows 虚拟化功能。安装前在“控制面板-程序-启用或关闭 Windows 功能”里确认“适用于 Linux 的 Windows 子系统”和“虚拟机平台”都已勾选。很多人碰到virtualization support not detected或者Docker Desktop failed to start这类报错十有八九是 BIOS 里的 VT-x/AMD-V 没开或者 Hyper-V、WSL2 没装全。装完之后在命令行敲wsl --status看一下 WSL 内核版本太旧了也要更新。Linux 用户注意CentOS 和 Ubuntu 的安装命令不一样但装完后都有一个必做动作——把当前用户加入 docker 组不然每次都要 sudo 前缀麻烦得要死。sudo usermod -aG docker $USER改完记得注销重新登录否则组权限不生效。这个动作虽然简单但很多人忽略导致后边每个 docker 命令都报 permission denied排查半天其实是这个问题。装完验证一下 Docker 是否正常docker version docker run hello-world能正常打印版本信息和 hello-world 的提示说明 Docker 环境没问题了。接下来就可以正式进入 Redis 部署环节。2. 快速部署从拉镜像到跑通第一个 Redis 实例2.1 拉取镜像与最简启动先拉镜像。Redis 官方镜像都在 Docker Hub 的 redis 仓库下直接指定版本标签别用 latest 打生产这是铁律docker pull redis:7.2版本号可以按需选7.x 是目前的主流稳定版6.2 也有不少存量项目在用。拉下来后确认一下docker images | grep redis输出里能看到redis 7.2 ...这样的行说明镜像已经就位。最简启动方式其实就一条命令docker run -d --name my-redis -p 6379:6379 redis:7.2拆开解释一下每个参数-d后台运行容器。--name my-redis给容器起个名字之后操作直接叫名字不用记容器 ID。-p 6379:6379把宿主机的 6379 端口映射到容器的 6379 端口。冒号左边是宿主机端口右边是容器内端口。redis:7.2使用的镜像名加标签。跑起来之后验证一下docker ps redis-cli -h 127.0.0.1 -p 6379 ping如果返回PONG说明 Redis 已经活着了。这条最简命令适合临时验证但有一个致命问题容器一删数据全没了配置也无法定制。所以实际使用必须做配置挂载和持久化见下一节。2.2 挂载配置文件和数据目录配置和数据这两件事都是在docker run时通过-v参数把宿主机目录挂载进容器里。先看完整命令mkdir -p /usr/local/redis/conf /usr/local/redis/data docker run -d \ --name my-redis \ -p 6379:6379 \ -v /usr/local/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /usr/local/redis/data:/data \ redis:7.2 \ redis-server /etc/redis/redis.conf这里有两个关键点需要说明。第一配置文件的路径和启动命令。官方镜像里 Redis 默认的配置路径是/usr/local/etc/redis/redis.conf但我习惯挂到/etc/redis/redis.conf然后把启动命令显式写成redis-server /etc/redis/redis.conf这样配置路径一目了然不容易出错。需要注意的是如果不把配置文件挂进去容器会以 Redis 的默认配置启动日志里会有Warning: no config file specified, using the default config的提示这时候你改不了密码、改不了持久化策略出错率很高。第二数据目录挂载。Redis 的持久化文件RDB 快照和 AOF 日志默认写在/data目录这也是官方镜像里WORKDIR指定的工作目录。把宿主机目录挂到/data就算容器删了重建数据还在宿主机上新容器一挂上来就能继续用。这个习惯一定要养成否则容器被误删或者升级重建的时候Redis 里缓存的数据全部归零如果是缓存数据库还好如果是存了业务状态的那就是事故了。在这里顺便提一下redis.conf的权限问题。宿主机挂载进容器的文件容器内进程如果要以非 root 身份运行可能出现权限不足读取不了配置的情况。官方镜像默认以 root 启动开发环境问题不大生产环境要关注一下。2.3 常用参数选型与配置解析关于配置文件我不建议从官方提供的完整 redis.conf 直接抄那文件 2000 多行很多配置用不上反而容易看花眼。实际生产里我常用的最小配置集大概是这样的# 不以后台守护进程方式运行让 redis-server 以前台方式跑在容器里 daemonize no # 数据目录持久化文件都放这里 dir /data # 开启 AOF 持久化 appendonly yes # AOF 刷盘策略每秒一次兼顾性能和安全 appendfsync everysec # 监听所有网卡地址容器内 IP 不受限 bind 0.0.0.0 # 访问密码 requirepass 你的密码 # 保护模式关闭否则 bind 之外的外部连接会被拒绝 protected-mode no # RDB 快照规则默认策略即可可自定义 save 900 1 save 300 10 save 60 10000逐条说一下背后的逻辑。daemonize no是容器场景里特别容易忽略的配置。Redis 默认配置里 daemonize 可能是 no但如果改成 yesRedis 会 fork 出一个后台进程容器里的前台进程直接退出Docker 会认为容器启动失败直接把它停掉。正确做法是在容器场景里始终保持前台运行。appendonly yes决定是否开启 AOF 持久化。Redis 有两种持久化方式RDB 是定期全量快照恢复快但可能在两次快照之间丢数据AOF 是记录每一条写操作的日志配合everysec刷盘策略最多丢一秒的数据。对绝大多数业务来说AOF 是必开的RDB 可以保留作为快速恢复的兜底。bind 0.0.0.0和protected-mode no是容器通信里的常见坑。Docker 默认的网络模式下容器有一个独立的 IP宿主机通过端口映射访问它。如果 Redis 的 bind 只写127.0.0.1那容器内部只能本机访问宿主机连不进去而 Redis 的 protected-mode 默认开启时非本机连接会被拒绝除非配置了密码。所以最简单的组合是 bind 监听所有网卡、protected-mode 关掉、再通过requirepass设置强密码来保障安全。requirepass自己设一个强密码别用123456这种。连接命令要带上密码redis-cli -h 127.0.0.1 -p 6379 -a 你的密码 ping配置写好后重启容器让配置生效docker restart my-redis再通过docker logs my-redis查看启动日志确认没有报错配置就生效了。到这里一个带密码、带持久化、可挂载配置的 Redis 单点实例就部署完成了。但实际项目里单点往往不够接下来进入到更实用的部分用 Docker Compose 编排多节点。3. 进阶实战用 Docker Compose 搭建主从和哨兵3.1 Compose 编排单节点的结构设计Docker Compose 是 Docker 官方的多容器编排工具用 YAML 文件定义一组服务一键启停。相比一条条写docker runCompose 的优势很明显配置写进文件版本化管理团队成员拉下来直接docker compose up -d就能复现一整套环境。Compose 文件的核心结构是三个层级services定义服务、networks定义网络、volumes定义数据卷。结合 Redis 的场景一个单节点的 Compose 文件长这样version: 3.8 services: redis: image: redis:7.2 container_name: my-redis restart: always ports: - 6379:6379 volumes: - ./conf/redis.conf:/etc/redis/redis.conf - redis-data:/data command: [redis-server, /etc/redis/redis.conf] networks: - redis-net volumes: redis-data: networks: redis-net: driver: bridge几个设计要点说下。restart: always很关键容器异常退出或 Docker 服务重启后会自动拉起 Redis 容器减少人工干预。网络这里我用的是自定义 bridge 网络redis-net。默认的 bridge 网络也能用但自定义网络的好处是容器间可以通过服务名直接解析 IP比如主从配置里写replicaof master 6379Compose 会自动把master解析成主节点容器的 IP。不用手动查 IP也不用--link这种老掉牙的做法这会让后续的配置和扩展舒服很多。数据卷redis-data是 Docker 管理的卷比直接挂载宿主机目录更规范备份迁移都方便。如果偏好宿主机目录也可以改成./data:/data。写完文件后启动docker compose up -d查看状态docker compose ps有一个细节提醒Compose 文件里的version字段在新版 Docker 里已经标记为废弃可以写也可以不写写了也不影响运行。不用纠结这个部分老教程里强调必须写 3.8 之类版本号新版 Comose 插件已经忽略它了。3.2 主从复制配置与验证现在升级一下需求。项目里缓存读多写少想把读的压力分摊出去或者担心单点故障就需要部署一主一从甚至一主多从。Redis 的主从复制逻辑不复杂从节点连接主节点主节点把全量数据发给从节点之后持续同步增量写操作。用 Compose 部署一主两从目录结构这样安排redis-stack/ ├── docker-compose.yml ├── master/ │ └── redis.conf ├── slave1/ │ └── redis.conf └── slave2/ │ └── redis.confcompose 文件关键部分如下services: master: image: redis:7.2 container_name: redis-master ports: - 6379:6379 volumes: - ./master/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] networks: - redis-net slave1: image: redis:7.2 container_name: redis-slave1 ports: - 6380:6379 volumes: - ./slave1/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] depends_on: - master networks: - redis-net slave2: image: redis:7.2 container_name: redis-slave2 ports: - 6381:6379 volumes: - ./slave2/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] depends_on: - master networks: - redis-net主节点的 redis.conf 沿用前面单节点的配置从节点的 redis.conf 关键增加一行replicaof master 6379因为 Compose 网络里服务名master就是主节点的 DNS 名称Redis 会自动解析。这里注意要写 6379因为从节点连的是主节点容器内的端口而不是宿主机映射的端口。主从节点都必须设置相同的requirepass。另外需要在从节点的配置里加上masterauth 你的密码这句很重要主节点开密码后从节点复制数据时要提供密码才能通过认证很多初次配主从的人忘了加这一行结果主从关系一直起不来日志里报MASTER - REPLICA sync started然后反复Connection error on master。启动后验证主从状态docker exec -it redis-master redis-cli -a 你的密码 info replication重点关注输出里的几项role:master connected_slaves:2 slave0:ip172.x.x.x,port6379,stateonline slave1:ip172.x.x.x,port6379,stateonline再进入从节点验证docker exec -it redis-slave1 redis-cli -a 你的密码 info replication输出里role:slave加master_link_status:up就代表复制链路是通的。有一个容易让人迷惑的点端口映射。我让主从容器的宿主机端口分别是 6379、6380、6381但容器内部 Redis 都是 6379。之所以这样映射是因为从节点配置里写replicaof master 6379这个 6379 是容器内端口跟宿主机端口没关系。很多新手在这里想不通总以为要写成映射后的端口实际上不需要。3.3 哨兵模式实现高可用主从能解决读扩展问题但解决不了一个痛点主节点挂了从节点不会自动升级成主节点整个写服务就断了。哨兵Sentinel模式就是来解决这个问题的它监控主节点状态发现主节点不可用后自动在从节点里选出一个新的主节点实现故障转移。用 Compose 加三个哨兵容器文件结构变成redis-stack/ ├── docker-compose.yml ├── master/redis.conf ├── slave1/redis.conf ├── slave2/redis.conf └── sentinel/ └── sentinel.conf哨兵的配置比较精简port 26379 dir /tmp sentinel monitor mymaster master 6379 2 sentinel auth-pass mymaster 你的密码 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000 sentinel parallel-syncs mymaster 1解释几个参数sentinel monitor mymaster master 6379 2监控名为 mymaster 的主节点地址是masterCompose 服务名端口 63792表示至少 2 个哨兵同意主节点挂了才触发故障转移。sentinel auth-pass mymaster 你的密码主节点开了 requirepass哨兵必须带密码才能通信。down-after-milliseconds判定主节点主观下线的时间这里设 5 秒。parallel-syncs故障转移后同时允许几个新从节点去做全量复制设 1 防止瞬时压力过大。Compose 里加哨兵服务sentinel1: image: redis:7.2 container_name: redis-sentinel1 ports: - 26379:26379 volumes: - ./sentinel/sentinel.conf:/etc/redis/sentinel.conf command: [redis-server, /etc/redis/sentinel.conf, --sentinel] depends_on: - master networks: - redis-net注意启动命令后面一定要跟--sentinel否则 Redis 会把它当普通服务启动端口行为都不对。哨兵一般部署奇数个比如 3 个因为投票需要多数同意才能故障转移2 个哨兵如果其中一个挂了就投不出结果了。实际生产我会部署 3 个哨兵容器分散到不同宿主机上这篇文章里演示的时候一个 Compose 文件内部署 3 个哨兵服务容器名分别是 sentinel1、sentinel2、sentinel3配置相同即可。验证哨兵是否工作docker exec -it redis-sentinel1 redis-cli -p 26379 sentinel master mymaster输出里能看到主节点的 IP、端口和状态信息。这里有一个比较有意思的细节输出里主节点地址会是172.x.x.x这样的容器网络 IP而不是宿主机的 IP因为哨兵是通过 Compose 网络连接 Redis 的。如果你在宿主机上用客户端连接哨兵需要连哨兵的宿主机映射端口26379再通过sentinel get-master-addr-by-name mymaster命令问出当前主节点在容器网络里的地址然后你还需要用宿主机映射的 6379 端口去连接这在生产环境里需要一个额外的服务发现环节开发环境验证的话知道这个映射关系就行不用过度纠结。手动做一次故障转移演练docker stop redis-master等待几秒后查看某个哨兵的日志docker logs redis-sentinel1 --tail 50日志里会出现switch-master相关的记录说明哨兵已经选出了新的主节点。再查看新主节点状态docker exec -it redis-slave1 redis-cli -a 你的密码 info replication如果输出role:master说明自动故障转移成功了。这个演练我建议每个团队都做一次不然真出事故的时候心里没底。4. 可视化客户端与日常运维排查4.1 客户端工具选型容器跑起来了命令行验证过了但日常开发里不可能总是敲命令。选择一个好用的可视化客户端能明显提升效率。市面上常见的几个工具我按实际使用体验对比一下工具跨平台免费程度特点Redis Desktop Manager是付费/旧版免费老牌工具新版收费免费版阉割较多Another Redis Desktop Manager是开源免费目前最推荐UI 现代化功能完善RedisInsight是官方免费Redis 官方出品自带内存分析适合专业调优TablePlus是部分免费数据库全家桶Redis 只是其中一项个人最常用的是 Another Redis Desktop ManagerGitHub 上直接搜就能找到开源免费支持 key 的树形浏览、命令行交互、慢日志查看、集群模式功能覆盖日常开发完全足够。连接的时候填宿主机 IP、映射端口和 requirepass 密码就行不需要额外配置。RedisInsight 我也装了它的内存分析功能很强大可以直观看到哪些 key 占内存最多、哪些大 key 拖慢性能排查线上问题的时候帮助很大。缺点是界面比 ARDM 重一些不适合经常开开关关的轻量使用。一个小提醒不管用哪个客户端连接 Redis 都建议先确认访问的安全性尤其是 Redis 绑定了0.0.0.0且没有密码的情况下公网环境可能被扫描器直接打进来。生产环境 Redis 端口不要暴露到公网内网访问也要通过安全组或防火墙限制来源 IP。4.2 常见问题与排查速查表把 docker 装 redis 过程中最常见的坑整理成一个速查表每个都是实战中真实遇到过的问题现象原因解决办法容器启动秒退配置里daemonize yes改成daemonize no前台运行宿主机连不上 Redisbind只绑了 127.0.0.1改成bind 0.0.0.0外部连接被拒绝protected-mode yes未关关闭保护模式或配置密码主从同步失败从节点未配masterauth从节点配置中加masterauth 密码容器重启后数据丢失没挂载数据目录把/data挂到宿主机或数据卷密码认证失败客户端命令没用-a连接时带密码参数docker compose命令不存在老版本没有 compose 插件装 docker-compose-plugin 或用docker-composeDocker Desktop 启动失败虚拟化未启用或 WSL2 异常检查 BIOS 虚拟化、WSL2 更新除了表格里的内容再展开讲两个容易误判的问题。第一个是 “Connection refused” 并不一定是 Redis 问题。我在实际排障时发现很多人一看到Connection refused就以为是 Redis 里面的配置问题结果查了半天下载日志。应该先确认几件事容器有没有起来docker ps里状态是 Up 还是 Exited端口映射有没有生效docker port myredis输出映射对不对宿主机防火墙有没有拦 6379 端口。把这几个排查完再去翻 Redis 日志。排障的顺序很重要先外后内先容器后应用能省大量时间。第二个是日志定位技巧。容器内 Redis 出问题第一件事必然是看日志docker logs my-redis docker logs --tail 100 my-redis如果日志信息不够还可以进入容器看完整日志文件。注意容器里 Redis 日志默认打到 stdout所以docker logs就能看到不用去容器里翻日志文件。这是 Docker 场景和物理机安装的一点区别物理机 Redis 日志写在文件里容器里则直接输出到标准输出。4.3 用容器内 redis-cli 做日常调试命令行虽然不如 GUI 直观但排障的时候比任何客户端都好使因为它在容器内直接执行不经过网络层能快速区分问题是不是出在网络或客户端配置上。进入容器执行命令docker exec -it my-redis /bin/bash redis-cli -a 你的密码或者不进入容器直接在宿主机上执行docker exec -it my-redis redis-cli -a 你的密码 ping docker exec -it my-redis redis-cli --raw keys user:*几个实用的调试命令# 查看所有 key--stat 可以实时监控 docker exec -it my-redis redis-cli -a 密码 --stat # 查看内存和 key 数量 docker exec -it my-redis redis-cli -a 密码 info keyspace docker exec -it my-redis redis-cli -a 密码 info memory # 查看慢日志排查慢查询很有用 docker exec -it my-redis redis-cli -a 密码 slowlog get 10 # 查看大 key扫描分析 docker exec -it my-redis redis-cli -a 密码 --bigkeys--bigkeys这个命令我强烈推荐定期跑一下Redis 里如果有特别大的 key比如一个几兆的字符串或者一个几万元素的 list会拖慢整个实例的性能。它会扫描整个实例并按类型统计最大 key扫完可以看到哪类数据有问题。这也是 RedisInsight 内存分析能做的但命令行版更方便快速定位。调试完记得退出容器exit就行。还有一个细节进入容器后再退出容器并不会让容器停止因为-it只是附加到容器的终端不影响主进程运行。5. 日常运维习惯与经验积累5.1 备份和恢复的正确姿势很多人以为 Redis 数据都在内存里不需要备份这是很大的误区。Redis 的持久化文件在/data目录下RDB 文件是dump.rdbAOF 文件是appendonly.aof。备份方式有两种一种直接拷贝持久化文件另一种用BGSAVE命令在线生成快照再拷贝。在 Docker 场景下我的习惯是直接对挂载的数据目录做文件级备份# 先触发一次 BGSAVE确保数据是最新的 docker exec -it my-redis redis-cli -a 密码 BGSAVE # 再备份数据目录 cp -r /usr/local/redis/data /backup/redis-20240101恢复时把备份的文件放回挂载目录重新启动容器即可。这里要特别提醒备份 AOF 文件前如果 AOF 正在写入直接拷贝可能出现文件不一致。稳妥的做法是先执行BGSAVE生成一份 RDB 快照然后备份 RDB 文件或者通过config get appendonly确认状态后短暂停写再拷贝避免文件写一半的问题。日常备份我一般用 RDB 文件就够了恢复速度快最多丢最后一次快照到故障之间的数据对大多数缓存场景可以接受。5.2 资源限制和容器健康检查生产环境里容器必须设置资源限制防止某个 Redis 实例把宿主机内存吃光。在docker run时可以加参数Compsoe 里也一样deploy: resources: limits: cpus: 1.0 memory: 1g这样 Redis 容器最多用 1 个 CPU 核心和 1GB 内存超出会触发 OOM而不会拖垮整个宿主机。健康检查也是容易忽略的一点。Redis 容器如果只是进程存活但内部出了问题Docker 依然认为它是健康的。可以在 Compose 里加上健康检查healthcheck: test: [CMD, redis-cli, -a, 密码, ping] interval: 30s timeout: 5s retries: 3redis-cli ping能返回 PONG 说明 Redis 正常响应否则 Docker 会标记容器为 unhealthy。这个状态可以配合监控系统做告警也可以配合depends_on条件控制服务启动顺序避免主从同步时从节点比主节点先起来导致连接失败。5.3 我踩过的一些印象深刻的坑最后分享几个比较典型的踩坑实例。第一个是版本升级的教训。有一次我从 Redis 6 升级到 7直接改了镜像标签重新跑容器结果客户端全部连不上查了半天才发现是 Redis 7 默认开启了 ACL 访问控制原来在 Redis 6 里配置的 requirepass 和新的 ACL 体系有冲突。后来老老实实对比了两版配置重新调整了认证方式才好起来。这个教训告诉我升级 Redis 大版本前一定要看官方配置变更说明不要想当然。第二个是端口冲突的坑。同一台宿主机上如果已经装了 MySQL 或者别的服务占用了 6379 端口docker run时会报端口绑定失败。这时候要么换宿主机映射端口比如-p 6380:6379要么把原来的服务停掉。在团队开发环境里我习惯提前规划端口分配表Redis 从 6379 开始递增避免同事之间互相抢端口。第三个是容器时区的坑。Redis 日志和TIME命令默认使用 UTC 时间国内使用时差 8 小时。排查问题看日志的时候总觉得时间对不上。解决方式是在启动容器时挂载时区文件volumes: - /etc/localtime:/etc/localtime:ro这样容器内时间就和宿主机同步了查日志的时候舒服很多。还有一次比较有意思。有人反馈 Redis 连不上怎么查都正常最后发现是 Docker Desktop 的 DNS 解析问题容器内解析宿主机主机名失败。这种问题跟 Redis 本身没关系是 Docker 网络配置的锅。遇到容器内访问不了宿主机服务在容器里用getent hosts host.docker.internal看能不能解析到地址Windows 和 macOS 的 Docker Desktop 通常自动支持这个特殊域名Linux 下的 Docker Engine 需要加extra_hosts配置才能用。5.4 关于 Redis 数据类型的几句额外分享既然装好了 Redis免不了要存数据。Redis 不止有简单的字符串缓存五种基本数据类型用好了能省下大量业务代码。我简单整理一下方便刚开始接触 Redis 的朋友String最常用的键值对缓存、计数器、分布式锁都能用它。Hash适合存储对象用户信息、商品详情可以单独修改某个字段比序列化整个对象效率高。List双向链表可以做消息队列、时间线、最新列表。Set去重集合适合做标签、关注关系、共同好友这类场景。ZSet有序集合排行榜、优先队列的标配带分数排序是它的核心能力。如果你用 Docker 只是搭个缓存服务String 可能够用但如果你准备用自己的 Redis 做更复杂的业务建议把 Hash 和 ZSet 的常用命令过一遍这两个在真实业务里利用率非常高。比如 ZSet 做排行榜一条ZREVRANGE就能拿前 N 名比在 MySQL 里排序再缓存简单太多了。拿同样的思路处理分布式锁的场景。网上能搜到不少 Redis 分布式锁的例子其实核心就几条命令SET key randomValue NX EX seconds加锁Lua 脚本判断 value 一致后 DEL 解锁。Docker 部署的 Redis 用来做分布式锁完全没问题需要注意的就是选主从架构时不要在主节点上加锁后在从节点上丢失了生产场景要考虑 RedLock 或者直接纯单机锁这里不展开但方向先给到。这些数据类型的技巧多说一句不是 Docker 特有的而是 Redis 本身的能力。用 Docker 把 Redis 跑起来后你获得的是一个完整能力的 Redis不要只把它当成一个能存 key-value 的黑盒子。个人在实际操作中的体会是Docker 装 Redis 这件事本身不难难的是把环境理解透、把配置目的搞清楚、把灾备意识和网络模型建立起来。一条docker run命令背后藏着端口映射、数据持久化、网络通信、认证安全几个维度的知识每一样都在生产环境里出过真实的事故。把基本功打牢后面不管是用 Compose 编排多节点还是接集群模式都会顺很多。最后再分享一个小技巧。如果你经常在多个项目里切换每个项目依赖不同版本的 Redis建议在宿主机上建一个固定的目录结构每个版本一套配置文件再写一个简单的 shell 脚本封装启动命令比如#!/bin/bash # 启动 Redis 6.2 docker run -d --name redis-6 \ -v ~/docker/redis/6.2/conf:/etc/redis \ -v ~/docker/redis/6.2/data:/data \ -p 6379:6379 redis:6.2 redis-server /etc/redis/redis.conf这样切项目的时候就是执行一个脚本的事不用每次翻文档回忆参数。这个习惯帮我省了太多时间也推荐给你。
