1. 为什么我建议用Docker跑Redis不止是省事这么简单做后端开发或运维的同学多多少少都跟Redis打过交道。缓存、会话、消息队列、分布式锁哪一样离得开它但提到在服务器上装Redis很多人第一反应还是去官网下载源码、编译、配systemd服务一条龙下来折腾半小时还算顺利的遇到个依赖冲突或者编译报错一个下午就这么交代了。我第一次在服务器上手动装Redis是在一台CentOS 7的老机器上。当时的场景很典型——项目急着上线需要Redis做缓存结果yum源里的版本老得掉渣只能走编译安装。下载源码倒是挺快结果编译时gcc版本不够升级gcc又牵扯到一堆动态库依赖最后还差点把系统的openssl给搞碎。从那之后我给自己立了个规矩能用容器跑的中间件绝不手动装。用Docker部署Redis核心解决的问题有三个环境隔离。Redis编译依赖gcc、jemalloc、openssl这些底层库跟系统自带的版本一旦打架排查起来特别头疼。容器把整个运行时环境打包好你只需要关心Redis本身至于宿主机上装的是什么发行版、依赖库有没有冲突完全不重要。版本切换成本极低。Redis 6.x和7.x在配置上有些差异手动装的话升级要备份、停服务、换二进制、改配置每一步都是风险点。Docker这边就是改个镜像标签一条命令搞定回滚同样简单。我现在的策略是项目里明确锁定镜像tag升级前先在一个测试容器里跑一遍稳了再切换生产。配置可复现。部署新服务器的时候手动装Redis的流程走一遍容易出错比如漏了设置密码、忘了改写持久化配置。用Docker的话把docker-compose文件往Git仓库里一放新机器上pull代码直接执行部署结果完全一致。这个优势在服务器数量变多之后尤其明显。但这里要泼一盆冷水Docker跑Redis不是零成本的银弹有几个坑必须提前知道。最典型的就是数据持久化。容器的特点是无状态容器一删里面写的文件全部没了。Redis作为缓存场景数据丢了不可怕但你要是有需要保留的数据不配置持久化就是直接裸奔。另一个坑是端口和网络的坑很多人刚用Docker的时候容器里Redis跑得好好的在宿主机上就是连不上往往是漏了端口映射或者绑定了错误的IP。这篇文章不扯那些虚的直接以一台全新的Linux服务器为例带你走完整套Docker部署Redis的流程从环境准备、安装Docker到Redis容器的密码配置、数据持久化再到连接测试和常见问题排查。整个流程走完你会得到一个开箱即用的Redis服务生产环境可直接参考。2. 环境准备先把Docker装好别用一键脚本2.1 打完这些命令服务器就绪我这里以Ubuntu 22.04 LTS服务器为例。如果你是CentOS或者Debian命令略有差异但思路一样。先确认系统信息和网络状态cat /etc/os-release uname -m ping -c 4 mirrors.cloud.tencent.com这里需要说明几个判断依据第一x86_64架构目前是绝对主流绝大多数Docker镜像都在这上面跑得最稳。如果你手里是ARM架构的服务器比如华为鲲鹏、阿里倚天这类我建议先别急后面我会单独说。第二ping不通公共镜像源不代表不能装Docker但说明当前网络环境可能有墙或DNS问题这一步早点发现好过装到一半才报错。如果系统是全新的先把基础软件包更新一下避免装Docker的过程中出现依赖问题sudo apt update sudo apt upgrade -y2.2 安装Docker引擎官方源是首选许多网上教程喜欢用一条曲线脚本安装Docker命令看起来简单粗暴curl -fsSL https://get.docker.com | bash -s docker这个脚本确实省事但我自己生产环境里几台服务器都发现过它带来的坑一是脚本运行时需要交互确认静默环境下会卡住二是它默认安装的是最新版本而最新版在个别内核上有兼容性问题。因此我更推荐从官方源安装过程可控、可重复。# 安装依赖 sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加稳定版仓库 echo deb [archamd64 signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io装完之后启动服务并设置开机自启sudo systemctl enable docker --now验证安装sudo docker --version sudo systemctl status docker --no-pager上面的docker --version会输出类似Docker version 24.0.7的信息而status命令显示active (running)这两条都正常环境就准备好了。2.3 ARM机器怎么办回到前面提到的ARM服务器。Docker本身是支持ARM64的安装方法几乎一样——上面官方源的命令会自动识别架构并下载对应安装包。真正的问题在于部分第三方镜像没有ARM64版本。好消息是Redis官方镜像redis从很早开始就提供linux/arm64版本所以在这个场景下你无需担心。如果你使用的是CentOS/RHEL系统把apt换成yum/dnf即可sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io sudo systemctl enable docker --now2.4 给孤儿用户授权免得每次都敲sudo我刚装完Docker后第一次用发现每个命令都要加sudo非常烦躁。这是因为当前用户不在docker用户组里。解决方法是把用户加进docker组然后重新登录终端sudo usermod -aG docker $USER需要注意把用户加入docker组等同于授予root权限。因为docker的操作本质上是root级的能执行docker命令的用户可以挂载宿主机目录、修改系统文件。这个权限给开发环境的普通用户尚可生产环境务必仅限管理员使用。3. 核心知识点密码访问与数据持久化一次说透3.1 Redis密码认证为什么默认不设密码这习惯很危险Redis的密码认证逻辑很简单配置文件里设置requirepass指令客户端在连接后需要使用AUTH命令进行认证。没通过认证任何读写命令都会被拒绝返回NOAUTH错误。那为什么很多刚部署的Redis默认不带密码因为Redis最初定位就是本机内的可信环境使用开发者默认你在一个封闭的内网里跑。但现实很骨感——互联网上存在大量扫描Redis未授权访问的僵尸程序它们会自动扫描6379端口发现没设密码就立刻写入计划任务或SSH公钥实现入侵。我有个朋友在云服务器上开过一个测试Redis28小时不到就被入侵写入了挖矿程序。至于密码的复杂度我的建议是抽查32位以上字符串混合大小写、数字和特殊符号。不要偷懒能用随机字符串就用随机字符串echo redis-$(openssl rand -hex 16)上面命令生成一段类似redis-8f2a1b3c...的随机密码然后复制到后面配置里使用。3.2 RDB与AOFRedis持久化的两条腿Redis是纯内存数据库数据默认只存在内存里。一旦进程退出所有数据都会消失。为此Redis提供了两种持久化机制RDB快照按约定时间间隔把当前内存里的全量数据生成一份二进制快照文件dump.rdb。优点是恢复速度快、文件紧凑、适合备份缺点是快照间隔期内如果宕机会丢失这段时间的写入数据。默认配置是900秒内1个键变化就触发一次快照60秒内1万个键变化也触发。AOF追加文件每次写操作以协议文本形式追加到aof文件尾部。优点是数据可靠性更高——可以配置成每次写入都fsync最多丢失一条写入缺点是文件体积大恢复速度比RDB慢且需要定期重写压缩。在实际生产中绝大多数场景建议RDB和AOF同时开启。RDB提供快速恢复的能力AOF弥补RDB可能丢数据的问题。Redis重启时会优先加载AOF文件如果存在因为AOF中的数据通常更新。那具体怎么配合使用看场景数据库缓存纯缓存允许丢失只开RDB甚至都可不开启持久化完全用内存做缓存。会话存储、排行榜等关键业务数据RDB AOF同时开启。消息队列Stream场景AOF必须开启并且appendfsync配置为everysec。3.3 Docker容器的数据持久化方案Docker容器的文件系统是临时的容器删除后数据就没了。要实现持久化最常用的方法就是把宿主机的目录或文件挂载到容器内部。Redis官方镜像声明了两个值得挂载的路径/data数据目录和/usr/local/etc/redis/redis.conf配置文件。官方镜像有个特性需要特别注意如果未指定配置文件Redis默认不会开启持久化。这意味着你光挂载了数据目录但没配置相应的redis.conf容器重启后数据照样全部丢失。很多人在这里踩坑以为是挂载没生效其实是配置文件里根本没写开启持久化的指令。3.4 为什么数据目录需要chown 999Redis官方镜像中容器进程默认以用户redis运行其uid/gid为999。如果直接把宿主机的root目录挂载到容器里由于权限不匹配Redis进程会报类似Cant open the append-only file: Permission denied的错误。解决方法是让宿主机目录的所有者与容器内的uid 999匹配sudo chown -R 999:999 /data/redis这一点细节我在实战中提醒过不少人他们都卡在这里出不去——明明配置都写对了数据目录也挂载了但Redis就是起不来日志里全是Permission denied。4. 完整实操docker-compose一键部署Redis4.1 项目目录规划我不建议直接裸跑docker run命令来部署生产服务因为命令行参数又长又难改日后维护全是泪。我的习惯是走docker-compose把配置、数据目录、容器定义全部集中管理。先在宿主机上建目录结构我的规划如下mkdir -p /opt/redis/{conf,data}目录说明/opt/redis/conf存放redis.conf配置文件/opt/redis/data存放RDB和AOF数据文件4.2 手写一份入职生产可用的redis.conf先说明一下既然是部署Redis服务我强烈建议你直接写自己的redis.conf而不是用官方镜像的默认配置。为什么因为默认配置没有设置requirepass也没有开启持久化需要每次启动时额外加的命令行参数来配置非常容易漏。把下面的配置保存为/opt/redis/conf/redis.conf# 允许任意IP连接依赖密码保护 bind 0.0.0.0 # 端口 port 6379 # 密码认证 requirepass MyChng3Me99! # RDB持久化60秒内1个键变化则保存快照 save 3600 1 save 300 100 save 60 10000 # 开启AOF持久化 appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 管理安全相关 protected-mode no我来逐条解释这里面几个关键项的考虑bind 0.0.0.0允许所有网卡上的连接。有人看到这个会紧张觉得暴露了所有网络。但实际上我们精心设置了requirepass又用了防火墙限制来源IP所以这里不必过多担心。如果你只想让宿主机的网络访问可以配置具体的IP地址。bind 127.0.0.1则仅允许本机访问此时任何外部客户端都无法连上。save规则的三个条件3600秒内至少1个键变化、300秒内至少100个键变化、60秒内至少10000个键变化满足任一即触发快照。这套配置是官方默认值对绝大多数场景足够温和——既不会频繁写盘也能在大规模写入时快速生成快照。appendfsync everysecAOF缓冲区每秒同步一次到磁盘。即时崩溃最多丢失1秒内的写入是性能与可靠性的折中方案。如果配置为always每次写操作都fsync性能下降明显配置为no则交给操作系统决定可靠性最差。auto-aof-rewriteAOF文件随着写入不断变大需要定期重写压缩。最小64MB且增长率达到100%时触发重写这样避免AOF文件无限膨胀。提示直接把requirepass里的MyChng3Me99!替换成你自己生成的随机字符串。密码一旦泄露等同于Redis数据裸奔尤其是还有0.0.0.0这种全开放监听的场景时更要谨慎。4.3 编写docker-compose.yml在/opt/redis目录下创建docker-compose.ymlversion: 3.8 services: redis: image: redis:7.2-alpine container_name: redis-server restart: always ports: - 6379:6379 volumes: - ./conf/redis.conf:/usr/local/etc/redis/redis.conf - ./data:/data command: [redis-server, /usr/local/etc/redis/redis.conf]文件里几个配置的意图说明image: redis:7.2-alpine选择Alpine版本而非默认的debian版本镜像体积小了近一半且Alpine的安全性口碑更好。如果你要更极致的稳定也可以锁定为redis:7.2.5-alpine这种具体到patch版本的tag。restart: always容器挂掉时自动拉起。这是Docker跑中间件的基本操作否则服务器一重启所有服务都得手动启动这在生产环境是不可接受的。ports: 6379:6379把容器内的6379端口映射到宿主机所有网卡的6379端口。如果只想让内网访问可以写10.10.0.5:6379:6379把监听IP收敛到内网地址。command覆盖镜像默认的启动命令。默认命令启动时不会加载任何配置文件所以要显式指定。这一步是新手最容易漏掉的。4.4 启动容器并验证在/opt/redis目录下执行cd /opt/redis docker compose up -d等待镜像拉取完成后用下面命令检查容器状态docker ps | grep redis-server docker logs redis-server --tail 50日志里如果出现Ready to accept connections tcp说明Redis服务已正常启动。再看一下持久化文件是否生成ls -lh /opt/redis/data/因为还没产生数据写入这时data目录可能是空的这符合预期。如果移动了之前的dump.rdb它会被自动加载。最后验证密码是否生效docker exec -it redis-server redis-cli进入交互模式后先试一条命令127.0.0.1:6379 PING你会看到NOAUTH Authentication required.这说明密码机制生效了。接下来认证127.0.0.1:6379 AUTH MyChng3Me99! OK 127.0.0.1:6379 PING PONG看到PONG而不是NOAUTH说明密码认证通过。到这一步Redis服务已经跑起来了并且密码保护与持久化都已生效。5. 验证持久化把容器删了再起来数据还在不在很多教程说我配置了持久化但从来没做过真正的故障演练。下面我带你做一个完整的验证往Redis写入测试数据然后强制删除容器重新启动看数据是否还在。第一步写入测试数据docker exec -it redis-server redis-cli -a MyChng3Me99!注意上面命令在shell history里留下了密码记录。为了安全可以改用环境变量方式export REDISCLI_AUTHMyChng3Me99! docker exec -it redis-server redis-cli设置REDISCLI_AUTH环境变量后redis-cli会自动带上认证信息避免密码泄漏到shell history中。在交互模式里写入几个测试键127.0.0.1:6379 SET test:name docker-redis OK 127.0.0.1:6379 SET test:count 100 OK 127.0.0.1:6379 BGSAVE OKBGSAVE命令在后台生成持久化快照。等待几秒后查看数据文件ls -lh /opt/redis/data/这时应该看到dump.rdb和appendonly.aof两个文件。dump.rdb是RDB快照文件appendonly.aof是AOF日志文件。第二步模拟灾难场景强制删除容器docker rm -f redis-server这一步跟服务器宕机的数据破坏程度不相上下——容器直接消失文件系统里的临时数据全部丢失。但我们的数据文件在/opt/redis/data上没有丢。第三步重新启动容器cd /opt/redis docker compose up -d等待容器启动后再次进入Redis并查看数据docker exec -it redis-server redis-cli 127.0.0.1:6379 AUTH MyChng3Me99! OK 127.0.0.1:6379 GET test:name docker-redis 127.0.0.1:6379 GET test:count 100数据完好无损。到这里持久化的可靠性已经得到验证——不是理论上的应该没问题而是实际验证过的确实没问题。可能有人会问为什么AOF文件和RDB文件都存在Redis重启时优先加载哪个答案是优先AOF因为AOF记录的数据更新。两者都存在并不冲突但如果AOF文件有问题Redis可能会拒绝启动。排查时可以通过redis-check-aof工具修复AOF文件。6. 生产部署的常见配置与注意事项6.1 内存限制与淘汰策略Redis是内存型数据库如果写入量大于物理内存就可能发生内存溢出。为此必须配置maxmemory限制并指定淘汰策略。在redis.conf里追加# 根据机器内存调整假设服务器内存16GRedis最多用4G maxmemory 4gb # 淘汰策略最近最少使用 maxmemory-policy allkeys-lru关于淘汰策略的选型看你的场景allkeys-lru所有键都参与LRU淘汰适合纯缓存场景。volatile-lru只淘汰设置了过期时间的键适合有基础数据需要保护、又有缓存需要的场景。noeviction内存写满后不再接受写入并返回错误适合作为消息队列等不能丢数据的场景。这个配置非常重要很多线上故障比如应用突然无法写入Redis排查半天发现是内存写满后触发了noeviction默认策略。6.2 保护Redis防火墙设置即使有了密码我依然建议在系统层面做一道防火墙隔离。以UFW为例sudo ufw allow 22/tcp sudo ufw allow 6379/tcp sudo ufw enable如果你只在内网使用Redis完全可以只允许内网网段访问sudo ufw allow from 10.0.0.0/8 to any port 6379不要让Redis端口对公网全部开放即使有密码也一样。密码可能会泄露但防火墙策略不会。6.3 监控与日志容器内日志怎么管Docker容器的stdout日志会打到宿主机通过docker logs命令查看。默认情况下该日志文件无上限长期运行可能占满磁盘导致服务器卡死。建议在/etc/docker/daemon.json里配置日志轮转{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }配置完成后重启Docker服务新容器会遵循该策略。旧的容器不受影响需要重建才能生效。6.4 从宿主机还是容器内连接Redis这是一个经常被问到的点。在宿主机上直接连Redis你可能会想到安装redis-cli工具。这确实可行但会给系统装一堆Redis相关的依赖比如jemalloc、openssl又回到了我们最早想解决的问题。我的建议是宿主机不装任何Redis客户端直接用docker exec进入容器执行redis-cli。这样不需要安装额外依赖而且使用体验一致。docker exec -it redis-server redis-cli如果需要从宿主机上的应用程序连接Redis那走的是网络TCP连接跟上面cli工具无关直接通过映射端口连接即可。6.5 定时备份持久化文件的保险上面验证了容器挂了数据还在但服务器硬盘挂了、数据库文件损坏这类事靠容器内的持久化可救不回来。这时候就需要一份定时备份。我提供一个简单的crontab备份方案每天凌晨3点把Redis数据目录打包压缩存到另一个目录或云存储mkdir -p /backup/redis写个备份脚本 /opt/redis/backup.sh#!/bin/bash tar czf /backup/redis/redis-backup-$(date \%Y\%m\%d).tar.gz -C /opt/redis/data . find /backup/redis -mtime 30 -type f -name *.tar.gz -delete然后加入crontab0 3 * * * bash /opt/redis/backup.sh这里用tar将整个数据目录打包压缩同时自动清理30天前的文件避免备份文件无限堆积。如果配合对象存储再挂载一个sync脚本就能实现异地容灾了。7. 高频问题排查与避坑指南7.1 容器启动失败日志提示Cant open the append-only file: Permission denied这是最常见的权限问题。原因已经解释过——容器内Redis以uid 999运行数据目录的所有者却不是这个uid。解决方法sudo chown -R 999:999 /opt/redis/data然后重启容器即可。如果你不想用999也可以手动指定运行时用户services: redis: image: redis:7.2-alpine user: 1000:1000但这样做的前提是数据目录的所有者是1000。两种方式二选一我更推荐前一种因为不需要额外记忆uid。7.2 宿主机能连Redis外部机器连不上这多半是端口映射和防火墙的问题。先确认端口监听情况ss -tlnp | grep 6379如果只有127.0.0.1:6379说明端口映射只绑定到了本机回环地址。检查docker-compose里的ports写法改成0.0.0.0:6379:6379或指定内网IP。如果监听在0.0.0.0还是连不上就检查云服务器安全组和系统防火墙UFW/iptables。安全组允许规则必须包含6379端口的入站方向。7.3 容器启动正常但AUTH就不通过确认密码是否正确最简单的方法是查看配置是否被容器正确加载docker exec -it redis-server redis-cli如果没设REDISCLI_AUTH首先提示NOAUTH。此时运行127.0.0.1:6379 CONFIG GET requirepass输出能够看到当前生效的密码值。如果跟配置不一致说明配置文件没有被容器加载。回看docker-compose.yml的command配置和卷挂载路径。7.4 数据文件丢失但容器运行正常如果你的data目录挂载正确但Redis日志提示加载了空的AOF文件排查顺序是先确认挂载是否生效再确认AOF文件是否存在最后用redis-check-aof检查AOF文件是否完整。AOF文件损坏时Redis会拒绝启动。这时可以docker run --rm -v /opt/redis/data:/data redis:7.2-alpine redis-check-aof --fix /data/appendonly.aof注意上面的docker run会临时创建一个容器不保留数据。命令中的路径/data/appendonly.aof是容器内部的路径对应宿主机/opt/redis/data/appendonly.aof。修复完成后再重新启动目标容持续化。7.5 Redis容器正常但应用连接超时连接超时通常是网络问题而不是Redis拒绝连接。排查思路一查应用所在机器能否ping通Redis服务器二查telnet看端口是否可达telnet 10.0.0.5 6379如果telnet也不通说明中间有防火墙拦截。如果telnet通但应用超时可能是应用侧连接池配置不合理比如连接池太小、重试策略不对。可以临时降低并发或者调整应用侧连接池参数再测试。7.6 端口6379被占用宿主机上原本就有其他服务占用6379端口。解决方案是把宿主机的映射端口改掉ports: - 16379:6379这样Redis在容器内还是6379在宿主机上对外暴露的是16379应用侧连接Redis时改成16379即可。8. 从单机到集群这套部署的扩展方向单机Docker部署Redis只是第一步。后续如果要扩展成高可用架构有几个方向可以考虑Redis主从复制用docker-compose同时部署主节点和从节点从节点通过replicaof指令跟随主节点。这个方案部署成本低能解决读扩展和部分高可用问题但主节点宕机后需要手动切换做不到自动故障转移。Redis Sentinel哨兵在主从基础上增加Sentinel节点实现对主节点的监控和自动故障转移。Docker部署Sentinel时需要注意网络模式需要是host模式因为Sentinel需要直接与宿主机网络通信。Redis Cluster集群当数据量大到单机内存无法承受时采用Cluster模式把数据分片到多个节点。Docker化部署Cluster有一些坑比如需要配置固定的IP和端口映射节点之间网络通信要放行。建议先在测试环境完整演练一遍再上生产。我个人建议的路径是先用单机Docker部署把业务跑起来等数据量和访问量上来后逐步迁移到主从哨兵再考虑Cluster。中间每一步都做好监控和备份生产环境的演进不是一蹴而就的。9. 最后分享一点个人体会这套Docker方式部署Redis的流程我在公司内部已经推了大半年好几个项目的缓存和会话服务都是这么跑起来的。用下来最大的感受是部署变成了一件可以标准化、可以重构、可以审计的事情。什么时候改了密码、什么时候升级了镜像、数据放在哪个目录全部记录在Git仓库里出了问题可以追溯这一点价值很大。还有一个小细节可能很多人没注意docker-compose.yml和redis.conf这些配置一定要跟项目一起纳入版本管理。切忌只把命令复制到笔记本里服务器一换什么都没了。我现在在公司新起一个项目第一件事就是把redis、mysql这类中间件的docker-compose丢到infra仓库里后续无论谁接手部署成本都极低。如果你是第一次上手建议先别直接改配置按上面的流程先跑通默认部署理解每一个配置项的作用再逐步调整。环境出了问题容器直接删掉重建比在一台手动装的机器上拆了装、装了拆体验好太多了。希望这篇保姆级教程能帮你少走一些弯路。部署的过程有问题欢迎按上面第7节的排查方法一步步来大多数问题都能自己解决。
1. 为什么我建议用Docker跑Redis不止是省事这么简单做后端开发或运维的同学多多少少都跟Redis打过交道。缓存、会话、消息队列、分布式锁哪一样离得开它但提到在服务器上装Redis很多人第一反应还是去官网下载源码、编译、配systemd服务一条龙下来折腾半小时还算顺利的遇到个依赖冲突或者编译报错一个下午就这么交代了。我第一次在服务器上手动装Redis是在一台CentOS 7的老机器上。当时的场景很典型——项目急着上线需要Redis做缓存结果yum源里的版本老得掉渣只能走编译安装。下载源码倒是挺快结果编译时gcc版本不够升级gcc又牵扯到一堆动态库依赖最后还差点把系统的openssl给搞碎。从那之后我给自己立了个规矩能用容器跑的中间件绝不手动装。用Docker部署Redis核心解决的问题有三个环境隔离。Redis编译依赖gcc、jemalloc、openssl这些底层库跟系统自带的版本一旦打架排查起来特别头疼。容器把整个运行时环境打包好你只需要关心Redis本身至于宿主机上装的是什么发行版、依赖库有没有冲突完全不重要。版本切换成本极低。Redis 6.x和7.x在配置上有些差异手动装的话升级要备份、停服务、换二进制、改配置每一步都是风险点。Docker这边就是改个镜像标签一条命令搞定回滚同样简单。我现在的策略是项目里明确锁定镜像tag升级前先在一个测试容器里跑一遍稳了再切换生产。配置可复现。部署新服务器的时候手动装Redis的流程走一遍容易出错比如漏了设置密码、忘了改写持久化配置。用Docker的话把docker-compose文件往Git仓库里一放新机器上pull代码直接执行部署结果完全一致。这个优势在服务器数量变多之后尤其明显。但这里要泼一盆冷水Docker跑Redis不是零成本的银弹有几个坑必须提前知道。最典型的就是数据持久化。容器的特点是无状态容器一删里面写的文件全部没了。Redis作为缓存场景数据丢了不可怕但你要是有需要保留的数据不配置持久化就是直接裸奔。另一个坑是端口和网络的坑很多人刚用Docker的时候容器里Redis跑得好好的在宿主机上就是连不上往往是漏了端口映射或者绑定了错误的IP。这篇文章不扯那些虚的直接以一台全新的Linux服务器为例带你走完整套Docker部署Redis的流程从环境准备、安装Docker到Redis容器的密码配置、数据持久化再到连接测试和常见问题排查。整个流程走完你会得到一个开箱即用的Redis服务生产环境可直接参考。2. 环境准备先把Docker装好别用一键脚本2.1 打完这些命令服务器就绪我这里以Ubuntu 22.04 LTS服务器为例。如果你是CentOS或者Debian命令略有差异但思路一样。先确认系统信息和网络状态cat /etc/os-release uname -m ping -c 4 mirrors.cloud.tencent.com这里需要说明几个判断依据第一x86_64架构目前是绝对主流绝大多数Docker镜像都在这上面跑得最稳。如果你手里是ARM架构的服务器比如华为鲲鹏、阿里倚天这类我建议先别急后面我会单独说。第二ping不通公共镜像源不代表不能装Docker但说明当前网络环境可能有墙或DNS问题这一步早点发现好过装到一半才报错。如果系统是全新的先把基础软件包更新一下避免装Docker的过程中出现依赖问题sudo apt update sudo apt upgrade -y2.2 安装Docker引擎官方源是首选许多网上教程喜欢用一条曲线脚本安装Docker命令看起来简单粗暴curl -fsSL https://get.docker.com | bash -s docker这个脚本确实省事但我自己生产环境里几台服务器都发现过它带来的坑一是脚本运行时需要交互确认静默环境下会卡住二是它默认安装的是最新版本而最新版在个别内核上有兼容性问题。因此我更推荐从官方源安装过程可控、可重复。# 安装依赖 sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加稳定版仓库 echo deb [archamd64 signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io装完之后启动服务并设置开机自启sudo systemctl enable docker --now验证安装sudo docker --version sudo systemctl status docker --no-pager上面的docker --version会输出类似Docker version 24.0.7的信息而status命令显示active (running)这两条都正常环境就准备好了。2.3 ARM机器怎么办回到前面提到的ARM服务器。Docker本身是支持ARM64的安装方法几乎一样——上面官方源的命令会自动识别架构并下载对应安装包。真正的问题在于部分第三方镜像没有ARM64版本。好消息是Redis官方镜像redis从很早开始就提供linux/arm64版本所以在这个场景下你无需担心。如果你使用的是CentOS/RHEL系统把apt换成yum/dnf即可sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io sudo systemctl enable docker --now2.4 给孤儿用户授权免得每次都敲sudo我刚装完Docker后第一次用发现每个命令都要加sudo非常烦躁。这是因为当前用户不在docker用户组里。解决方法是把用户加进docker组然后重新登录终端sudo usermod -aG docker $USER需要注意把用户加入docker组等同于授予root权限。因为docker的操作本质上是root级的能执行docker命令的用户可以挂载宿主机目录、修改系统文件。这个权限给开发环境的普通用户尚可生产环境务必仅限管理员使用。3. 核心知识点密码访问与数据持久化一次说透3.1 Redis密码认证为什么默认不设密码这习惯很危险Redis的密码认证逻辑很简单配置文件里设置requirepass指令客户端在连接后需要使用AUTH命令进行认证。没通过认证任何读写命令都会被拒绝返回NOAUTH错误。那为什么很多刚部署的Redis默认不带密码因为Redis最初定位就是本机内的可信环境使用开发者默认你在一个封闭的内网里跑。但现实很骨感——互联网上存在大量扫描Redis未授权访问的僵尸程序它们会自动扫描6379端口发现没设密码就立刻写入计划任务或SSH公钥实现入侵。我有个朋友在云服务器上开过一个测试Redis28小时不到就被入侵写入了挖矿程序。至于密码的复杂度我的建议是抽查32位以上字符串混合大小写、数字和特殊符号。不要偷懒能用随机字符串就用随机字符串echo redis-$(openssl rand -hex 16)上面命令生成一段类似redis-8f2a1b3c...的随机密码然后复制到后面配置里使用。3.2 RDB与AOFRedis持久化的两条腿Redis是纯内存数据库数据默认只存在内存里。一旦进程退出所有数据都会消失。为此Redis提供了两种持久化机制RDB快照按约定时间间隔把当前内存里的全量数据生成一份二进制快照文件dump.rdb。优点是恢复速度快、文件紧凑、适合备份缺点是快照间隔期内如果宕机会丢失这段时间的写入数据。默认配置是900秒内1个键变化就触发一次快照60秒内1万个键变化也触发。AOF追加文件每次写操作以协议文本形式追加到aof文件尾部。优点是数据可靠性更高——可以配置成每次写入都fsync最多丢失一条写入缺点是文件体积大恢复速度比RDB慢且需要定期重写压缩。在实际生产中绝大多数场景建议RDB和AOF同时开启。RDB提供快速恢复的能力AOF弥补RDB可能丢数据的问题。Redis重启时会优先加载AOF文件如果存在因为AOF中的数据通常更新。那具体怎么配合使用看场景数据库缓存纯缓存允许丢失只开RDB甚至都可不开启持久化完全用内存做缓存。会话存储、排行榜等关键业务数据RDB AOF同时开启。消息队列Stream场景AOF必须开启并且appendfsync配置为everysec。3.3 Docker容器的数据持久化方案Docker容器的文件系统是临时的容器删除后数据就没了。要实现持久化最常用的方法就是把宿主机的目录或文件挂载到容器内部。Redis官方镜像声明了两个值得挂载的路径/data数据目录和/usr/local/etc/redis/redis.conf配置文件。官方镜像有个特性需要特别注意如果未指定配置文件Redis默认不会开启持久化。这意味着你光挂载了数据目录但没配置相应的redis.conf容器重启后数据照样全部丢失。很多人在这里踩坑以为是挂载没生效其实是配置文件里根本没写开启持久化的指令。3.4 为什么数据目录需要chown 999Redis官方镜像中容器进程默认以用户redis运行其uid/gid为999。如果直接把宿主机的root目录挂载到容器里由于权限不匹配Redis进程会报类似Cant open the append-only file: Permission denied的错误。解决方法是让宿主机目录的所有者与容器内的uid 999匹配sudo chown -R 999:999 /data/redis这一点细节我在实战中提醒过不少人他们都卡在这里出不去——明明配置都写对了数据目录也挂载了但Redis就是起不来日志里全是Permission denied。4. 完整实操docker-compose一键部署Redis4.1 项目目录规划我不建议直接裸跑docker run命令来部署生产服务因为命令行参数又长又难改日后维护全是泪。我的习惯是走docker-compose把配置、数据目录、容器定义全部集中管理。先在宿主机上建目录结构我的规划如下mkdir -p /opt/redis/{conf,data}目录说明/opt/redis/conf存放redis.conf配置文件/opt/redis/data存放RDB和AOF数据文件4.2 手写一份入职生产可用的redis.conf先说明一下既然是部署Redis服务我强烈建议你直接写自己的redis.conf而不是用官方镜像的默认配置。为什么因为默认配置没有设置requirepass也没有开启持久化需要每次启动时额外加的命令行参数来配置非常容易漏。把下面的配置保存为/opt/redis/conf/redis.conf# 允许任意IP连接依赖密码保护 bind 0.0.0.0 # 端口 port 6379 # 密码认证 requirepass MyChng3Me99! # RDB持久化60秒内1个键变化则保存快照 save 3600 1 save 300 100 save 60 10000 # 开启AOF持久化 appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 管理安全相关 protected-mode no我来逐条解释这里面几个关键项的考虑bind 0.0.0.0允许所有网卡上的连接。有人看到这个会紧张觉得暴露了所有网络。但实际上我们精心设置了requirepass又用了防火墙限制来源IP所以这里不必过多担心。如果你只想让宿主机的网络访问可以配置具体的IP地址。bind 127.0.0.1则仅允许本机访问此时任何外部客户端都无法连上。save规则的三个条件3600秒内至少1个键变化、300秒内至少100个键变化、60秒内至少10000个键变化满足任一即触发快照。这套配置是官方默认值对绝大多数场景足够温和——既不会频繁写盘也能在大规模写入时快速生成快照。appendfsync everysecAOF缓冲区每秒同步一次到磁盘。即时崩溃最多丢失1秒内的写入是性能与可靠性的折中方案。如果配置为always每次写操作都fsync性能下降明显配置为no则交给操作系统决定可靠性最差。auto-aof-rewriteAOF文件随着写入不断变大需要定期重写压缩。最小64MB且增长率达到100%时触发重写这样避免AOF文件无限膨胀。提示直接把requirepass里的MyChng3Me99!替换成你自己生成的随机字符串。密码一旦泄露等同于Redis数据裸奔尤其是还有0.0.0.0这种全开放监听的场景时更要谨慎。4.3 编写docker-compose.yml在/opt/redis目录下创建docker-compose.ymlversion: 3.8 services: redis: image: redis:7.2-alpine container_name: redis-server restart: always ports: - 6379:6379 volumes: - ./conf/redis.conf:/usr/local/etc/redis/redis.conf - ./data:/data command: [redis-server, /usr/local/etc/redis/redis.conf]文件里几个配置的意图说明image: redis:7.2-alpine选择Alpine版本而非默认的debian版本镜像体积小了近一半且Alpine的安全性口碑更好。如果你要更极致的稳定也可以锁定为redis:7.2.5-alpine这种具体到patch版本的tag。restart: always容器挂掉时自动拉起。这是Docker跑中间件的基本操作否则服务器一重启所有服务都得手动启动这在生产环境是不可接受的。ports: 6379:6379把容器内的6379端口映射到宿主机所有网卡的6379端口。如果只想让内网访问可以写10.10.0.5:6379:6379把监听IP收敛到内网地址。command覆盖镜像默认的启动命令。默认命令启动时不会加载任何配置文件所以要显式指定。这一步是新手最容易漏掉的。4.4 启动容器并验证在/opt/redis目录下执行cd /opt/redis docker compose up -d等待镜像拉取完成后用下面命令检查容器状态docker ps | grep redis-server docker logs redis-server --tail 50日志里如果出现Ready to accept connections tcp说明Redis服务已正常启动。再看一下持久化文件是否生成ls -lh /opt/redis/data/因为还没产生数据写入这时data目录可能是空的这符合预期。如果移动了之前的dump.rdb它会被自动加载。最后验证密码是否生效docker exec -it redis-server redis-cli进入交互模式后先试一条命令127.0.0.1:6379 PING你会看到NOAUTH Authentication required.这说明密码机制生效了。接下来认证127.0.0.1:6379 AUTH MyChng3Me99! OK 127.0.0.1:6379 PING PONG看到PONG而不是NOAUTH说明密码认证通过。到这一步Redis服务已经跑起来了并且密码保护与持久化都已生效。5. 验证持久化把容器删了再起来数据还在不在很多教程说我配置了持久化但从来没做过真正的故障演练。下面我带你做一个完整的验证往Redis写入测试数据然后强制删除容器重新启动看数据是否还在。第一步写入测试数据docker exec -it redis-server redis-cli -a MyChng3Me99!注意上面命令在shell history里留下了密码记录。为了安全可以改用环境变量方式export REDISCLI_AUTHMyChng3Me99! docker exec -it redis-server redis-cli设置REDISCLI_AUTH环境变量后redis-cli会自动带上认证信息避免密码泄漏到shell history中。在交互模式里写入几个测试键127.0.0.1:6379 SET test:name docker-redis OK 127.0.0.1:6379 SET test:count 100 OK 127.0.0.1:6379 BGSAVE OKBGSAVE命令在后台生成持久化快照。等待几秒后查看数据文件ls -lh /opt/redis/data/这时应该看到dump.rdb和appendonly.aof两个文件。dump.rdb是RDB快照文件appendonly.aof是AOF日志文件。第二步模拟灾难场景强制删除容器docker rm -f redis-server这一步跟服务器宕机的数据破坏程度不相上下——容器直接消失文件系统里的临时数据全部丢失。但我们的数据文件在/opt/redis/data上没有丢。第三步重新启动容器cd /opt/redis docker compose up -d等待容器启动后再次进入Redis并查看数据docker exec -it redis-server redis-cli 127.0.0.1:6379 AUTH MyChng3Me99! OK 127.0.0.1:6379 GET test:name docker-redis 127.0.0.1:6379 GET test:count 100数据完好无损。到这里持久化的可靠性已经得到验证——不是理论上的应该没问题而是实际验证过的确实没问题。可能有人会问为什么AOF文件和RDB文件都存在Redis重启时优先加载哪个答案是优先AOF因为AOF记录的数据更新。两者都存在并不冲突但如果AOF文件有问题Redis可能会拒绝启动。排查时可以通过redis-check-aof工具修复AOF文件。6. 生产部署的常见配置与注意事项6.1 内存限制与淘汰策略Redis是内存型数据库如果写入量大于物理内存就可能发生内存溢出。为此必须配置maxmemory限制并指定淘汰策略。在redis.conf里追加# 根据机器内存调整假设服务器内存16GRedis最多用4G maxmemory 4gb # 淘汰策略最近最少使用 maxmemory-policy allkeys-lru关于淘汰策略的选型看你的场景allkeys-lru所有键都参与LRU淘汰适合纯缓存场景。volatile-lru只淘汰设置了过期时间的键适合有基础数据需要保护、又有缓存需要的场景。noeviction内存写满后不再接受写入并返回错误适合作为消息队列等不能丢数据的场景。这个配置非常重要很多线上故障比如应用突然无法写入Redis排查半天发现是内存写满后触发了noeviction默认策略。6.2 保护Redis防火墙设置即使有了密码我依然建议在系统层面做一道防火墙隔离。以UFW为例sudo ufw allow 22/tcp sudo ufw allow 6379/tcp sudo ufw enable如果你只在内网使用Redis完全可以只允许内网网段访问sudo ufw allow from 10.0.0.0/8 to any port 6379不要让Redis端口对公网全部开放即使有密码也一样。密码可能会泄露但防火墙策略不会。6.3 监控与日志容器内日志怎么管Docker容器的stdout日志会打到宿主机通过docker logs命令查看。默认情况下该日志文件无上限长期运行可能占满磁盘导致服务器卡死。建议在/etc/docker/daemon.json里配置日志轮转{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }配置完成后重启Docker服务新容器会遵循该策略。旧的容器不受影响需要重建才能生效。6.4 从宿主机还是容器内连接Redis这是一个经常被问到的点。在宿主机上直接连Redis你可能会想到安装redis-cli工具。这确实可行但会给系统装一堆Redis相关的依赖比如jemalloc、openssl又回到了我们最早想解决的问题。我的建议是宿主机不装任何Redis客户端直接用docker exec进入容器执行redis-cli。这样不需要安装额外依赖而且使用体验一致。docker exec -it redis-server redis-cli如果需要从宿主机上的应用程序连接Redis那走的是网络TCP连接跟上面cli工具无关直接通过映射端口连接即可。6.5 定时备份持久化文件的保险上面验证了容器挂了数据还在但服务器硬盘挂了、数据库文件损坏这类事靠容器内的持久化可救不回来。这时候就需要一份定时备份。我提供一个简单的crontab备份方案每天凌晨3点把Redis数据目录打包压缩存到另一个目录或云存储mkdir -p /backup/redis写个备份脚本 /opt/redis/backup.sh#!/bin/bash tar czf /backup/redis/redis-backup-$(date \%Y\%m\%d).tar.gz -C /opt/redis/data . find /backup/redis -mtime 30 -type f -name *.tar.gz -delete然后加入crontab0 3 * * * bash /opt/redis/backup.sh这里用tar将整个数据目录打包压缩同时自动清理30天前的文件避免备份文件无限堆积。如果配合对象存储再挂载一个sync脚本就能实现异地容灾了。7. 高频问题排查与避坑指南7.1 容器启动失败日志提示Cant open the append-only file: Permission denied这是最常见的权限问题。原因已经解释过——容器内Redis以uid 999运行数据目录的所有者却不是这个uid。解决方法sudo chown -R 999:999 /opt/redis/data然后重启容器即可。如果你不想用999也可以手动指定运行时用户services: redis: image: redis:7.2-alpine user: 1000:1000但这样做的前提是数据目录的所有者是1000。两种方式二选一我更推荐前一种因为不需要额外记忆uid。7.2 宿主机能连Redis外部机器连不上这多半是端口映射和防火墙的问题。先确认端口监听情况ss -tlnp | grep 6379如果只有127.0.0.1:6379说明端口映射只绑定到了本机回环地址。检查docker-compose里的ports写法改成0.0.0.0:6379:6379或指定内网IP。如果监听在0.0.0.0还是连不上就检查云服务器安全组和系统防火墙UFW/iptables。安全组允许规则必须包含6379端口的入站方向。7.3 容器启动正常但AUTH就不通过确认密码是否正确最简单的方法是查看配置是否被容器正确加载docker exec -it redis-server redis-cli如果没设REDISCLI_AUTH首先提示NOAUTH。此时运行127.0.0.1:6379 CONFIG GET requirepass输出能够看到当前生效的密码值。如果跟配置不一致说明配置文件没有被容器加载。回看docker-compose.yml的command配置和卷挂载路径。7.4 数据文件丢失但容器运行正常如果你的data目录挂载正确但Redis日志提示加载了空的AOF文件排查顺序是先确认挂载是否生效再确认AOF文件是否存在最后用redis-check-aof检查AOF文件是否完整。AOF文件损坏时Redis会拒绝启动。这时可以docker run --rm -v /opt/redis/data:/data redis:7.2-alpine redis-check-aof --fix /data/appendonly.aof注意上面的docker run会临时创建一个容器不保留数据。命令中的路径/data/appendonly.aof是容器内部的路径对应宿主机/opt/redis/data/appendonly.aof。修复完成后再重新启动目标容持续化。7.5 Redis容器正常但应用连接超时连接超时通常是网络问题而不是Redis拒绝连接。排查思路一查应用所在机器能否ping通Redis服务器二查telnet看端口是否可达telnet 10.0.0.5 6379如果telnet也不通说明中间有防火墙拦截。如果telnet通但应用超时可能是应用侧连接池配置不合理比如连接池太小、重试策略不对。可以临时降低并发或者调整应用侧连接池参数再测试。7.6 端口6379被占用宿主机上原本就有其他服务占用6379端口。解决方案是把宿主机的映射端口改掉ports: - 16379:6379这样Redis在容器内还是6379在宿主机上对外暴露的是16379应用侧连接Redis时改成16379即可。8. 从单机到集群这套部署的扩展方向单机Docker部署Redis只是第一步。后续如果要扩展成高可用架构有几个方向可以考虑Redis主从复制用docker-compose同时部署主节点和从节点从节点通过replicaof指令跟随主节点。这个方案部署成本低能解决读扩展和部分高可用问题但主节点宕机后需要手动切换做不到自动故障转移。Redis Sentinel哨兵在主从基础上增加Sentinel节点实现对主节点的监控和自动故障转移。Docker部署Sentinel时需要注意网络模式需要是host模式因为Sentinel需要直接与宿主机网络通信。Redis Cluster集群当数据量大到单机内存无法承受时采用Cluster模式把数据分片到多个节点。Docker化部署Cluster有一些坑比如需要配置固定的IP和端口映射节点之间网络通信要放行。建议先在测试环境完整演练一遍再上生产。我个人建议的路径是先用单机Docker部署把业务跑起来等数据量和访问量上来后逐步迁移到主从哨兵再考虑Cluster。中间每一步都做好监控和备份生产环境的演进不是一蹴而就的。9. 最后分享一点个人体会这套Docker方式部署Redis的流程我在公司内部已经推了大半年好几个项目的缓存和会话服务都是这么跑起来的。用下来最大的感受是部署变成了一件可以标准化、可以重构、可以审计的事情。什么时候改了密码、什么时候升级了镜像、数据放在哪个目录全部记录在Git仓库里出了问题可以追溯这一点价值很大。还有一个小细节可能很多人没注意docker-compose.yml和redis.conf这些配置一定要跟项目一起纳入版本管理。切忌只把命令复制到笔记本里服务器一换什么都没了。我现在在公司新起一个项目第一件事就是把redis、mysql这类中间件的docker-compose丢到infra仓库里后续无论谁接手部署成本都极低。如果你是第一次上手建议先别直接改配置按上面的流程先跑通默认部署理解每一个配置项的作用再逐步调整。环境出了问题容器直接删掉重建比在一台手动装的机器上拆了装、装了拆体验好太多了。希望这篇保姆级教程能帮你少走一些弯路。部署的过程有问题欢迎按上面第7节的排查方法一步步来大多数问题都能自己解决。
