1. 为什么非要用Docker安装Redis1.1 传统安装Redis的三个痛点直接在你的服务器上用源码编译或者用包管理器装Redis通常要经历这些事下载源码包、装gcc编译依赖、make make install、手工写systemd服务文件或者用redis-server指定配置文件、处理数据目录权限、后面升级还要重新走一遍流程。如果一台机器上同时跑多个项目每个项目要求Redis版本还不一样那就更难搞。我早年间就在生产环境遇到过Redis版本冲突的问题升级一个服务的Redis结果另外一个项目的老代码直接不兼容那个排查过程是真的难受。还有环境差异的问题本机CentOS上的Redis跑得好好的到了Ubuntu的服务器上Redis版本和内核配置不一样自带的redis.conf路径不一样就连日志输出的格式都对不上。这种“在这里能跑到那里就炸”的情况对运维新手来说非常伤人。再加上Windows上的Redis从官网往往拿不到正式版很多人只能跑到博客里找第三方编译包下载下来还要担心有没有被植入后门。1.2 Docker到底解决了什么Docker的解决思路特别朴素把Redis和它的运行环境一起打包成一个镜像运行的时候直接把这个镜像启动成容器。镜像里面有官方的Redis二进制、正确的系统依赖、合理的默认配置相当于把一个完整的运行环境固化成了文件。这样做的好处我直接列一下启动快拉取镜像之后一行docker run就能起一个Redis实例不需要编译、不需要安装依赖。版本隔离同一台机器可以同时跑redis:6和redis:7的两个容器互不干扰项目需要哪个版本就映射哪个版本。环境一致本机、测试机、生产机的Redis环境完全一致不会出现“本机能跑服务器不能跑”的情况。迁移方便把Docker命令或者docker-compose.yml文件拷到另一台机器上照样能跑起一模一样的Redis。对于快速验证技术方案、学习Redis、或者在公司多人协作交付项目用Docker管理Redis几乎是当下最省心的方案。这也是我写这篇博文的初衷把一次完整的Docker安装Redis过程记录下来既有最基础的启动命令也有配置持久化、密码、可视化工具这些实战中一定会用到的东西。文章里的所有操作我都实测过一遍你可以放心照着做。2. 先把Docker准备好2.1 Linux环境安装Docker在开始装Redis之前必须先保证本机有可用的Docker环境。国内服务器最常用的是Ubuntu和CentOS我用这两个系统各走一遍安装流程。Ubuntu系统推荐用官方apt源安装。先把依赖装齐sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release添加Docker官方GPG密钥和软件源sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null然后更新索引并安装Docker引擎顺手把compose插件也装上sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginCentOS这边用yum。先装yum-utilssudo 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 docker-buildx-plugin docker-compose-plugin安装完成后把Docker服务启动并设置为开机自启sudo systemctl enable docker --now最后用docker version确认安装成功。要留意一点Docker引擎装好之后普通用户直接执行docker命令时会报权限错误这是因为Docker的守护进程以root身份运行控制文件的所有者是root。最简单的解决办法是把当前用户加入docker用户组sudo usermod -aG docker $USER改完用户组之后重新登录终端docker命令就能直接用了。2.2 Windows和macOS上的Docker DesktopWindows上安装Docker最常规的方式是装Docker Desktop。很多人装完之后第一次启动直接弹一个“Docker Desktop failed to start because virtualization support is not detected”的错误这个报错的原因和解决办法要单独说清楚。这一步的关键是开启电脑的虚拟化功能。检查步骤是打开任务管理器切到“性能”标签页看CPU一栏右下角是否有“虚拟化已启用”。如果显示“已启用”那就说明BIOS里面开好了问题可能在Hyper-V组件没打开。可以在控制面板里打开“启用或关闭Windows功能”勾上“Hyper-V”和“Windows虚拟机监控程序平台”然后重启。如果你用的是Windows 11家庭版系统本身不带Hyper-V那就勾选“Windows虚拟机监控程序平台”和“适用于Linux的Windows子系统”这两个功能同样能解决问题。如果BIOS里虚拟化没开需要进BIOS设置在Advanced或CPU Configuration里找到类似Intel Virtualization Technology或者SVM Mode的选项状态改为Enabled。这一步做完再看Docker Desktop就正常了。macOS这边就简单很多装上Docker Desktop之后菜单栏出现鲸鱼图标就说明启动了。如果遇到资源占用过高的问题在Settings里调低CPU和内存分配即可不要无脑给满。在Windows上确认Docker是否正常可以在PowerShell或者cmd里跑一句docker version能正常输出版本号说明Docker Desktop已经和底层虚拟机打通了。如果你用WSL2后台运行Docker遇到“failed to connect to the docker api at npipe:////./pipe/docker-desktop-linux”这样的提示大概率是Docker Desktop的服务没完全启动或者WSL的内核版本太旧。解决办法是右键托盘区的鲸鱼图标选择“Restart”如果还不行就执行wsl --update更新内核然后再重启Docker Desktop。3. 一行命令跑起Redis3.1 拉取镜像与首次启动Docker环境准备好之后重点就来了。先用docker pull把官方Redis镜像拉下来docker pull redis:7.0我习惯把版本号写明确直接用最新标签redis:latest虽然省事但在项目里容易出现“昨天还能跑今天重新构建就换个Redis版本”的问题。更稳妥的做法是固定到主版本比如redis:7.0或者redis:6.2既避免镜像过大又能让后续的依赖关系清晰。拉完镜像后先跑一个最简单的单机Redis容器用命令行交互的方式观察效果docker run -d --name my-redis -p 6379:6379 redis:7.0这条命令的意思是把一个名为my-redis的容器放到后台运行宿主机上的6379端口映射到容器内部的6379端口。默认情况下Redis的监听端口就是6379Docker镜像里的默认配置允许任何IP连接且不设置密码。如果你只是本地快速验证某个功能这个命令完全可以满足需求。跑起来以后用docker ps能看到容器处于Up状态再用docker logs my-redis查看启动日志如果能看到类似“Ready to accept connections”的字样说明Redis已经正常起来了。3.2 端口映射与客户端验证容器启动了接下来肯定要验证能不能连上。如果本机装了redis-cli直接输入redis-cli -p 6379 ping看到PONG就代表通了。如果没有客户端工具也可以直接进入容器内部操作docker exec -it my-redis redis-cli这行命令的本质是用docker exec进入运行中的容器在容器内执行redis-cli命令后面如果想退出输入quit就行。也可以在进去后直接测试写入和读取set hello docker get hello能正常读写说明这条链路是通的。遇到容器内的redis-cli连不上多数是因为容器内默认将监听地址绑定了127.0.0.1但redis:7.0官方镜像在Dockerfile中已经做了处理默认是0.0.0.0所以不用太担心。3.3 设置密码与保护模式不过上面这样直接对外开放存在隐患Redis默认没有密码如果端口暴露在公网很容易引来扫描脚本直接把数据刷掉。实测中我就见过不少因为Redis裸奔导致的挖矿入侵事件所以生产环境至少要做好这几层防护第一层在启动容器时通过命令行参数设置密码。可以用下面的命令启动一个带密码的Redis容器docker run -d --name my-redis \ -p 6379:6379 \ --requirepass your-strong-password \ redis:7.0需要说明的是Redis官方镜像的entrypoint会把你通过Docker命令行参数指定的--requirepass传给redis-server这个方式用于快速验证没问题但是正式环境我更推荐用配置文件管理。第二层是理解和开启protected-mode。Redis在没有任何显式绑定和密码配置的时候自动开启保护模式只允许本机回环地址访问从外部连接会被拒绝。如果你看到日志里出现“DENIED Redis is running in protected mode”原因就是没有配置密码且绑定了非回环地址。确认了访问来源和密码策略后再用配置文件或者启动参数解除。第三层是云服务器的安全组和防火墙规则只对可信IP开放6379端口切忌对0.0.0.0开放。很多网上爆出的数据被勒索的案例根因就是端口裸奔加没有密码。4. 让数据不丢持久化与配置文件挂载4.1 容器中的数据落在哪里先泼一盆冷水如果你直接执行前面的启动命令并往里写数据然后执行docker rm my-redis把容器删掉Redis里的数据会全部消失。原因很简单容器就像一个沙盒容器运行期间写入的数据都保存在容器可写层里这个可写层随着容器删除一起被清掉。这个问题在开发环境里可能无所谓但在生产环境就是灾难。解决这个问题的标准做法是用数据卷或者宿主机目录挂载。在Docker里把宿主机上的某个目录或数据卷挂载到容器内的数据目录Redis写到容器内/data目录的数据会同步落到宿主机容器删了数据也还在。一个典型的带持久化的启动命令长这样docker run -d --name my-redis \ -p 6379:6379 \ -v /mydata/redis/data:/data \ redis:7.0这里我把宿主机/mydata/redis/data目录挂载到容器的/data目录Redis默认持久化的dump.rdb和appendonly.aof都会写到这个数据目录里面。这样在删除容器之前只要用了同样的挂载路径再启动一个新容器Redis就能自动加载旧数据。4.2 挂载redis.conf配置文件持久化目录解决了数据丢失的问题但Redis的配置还是要另外处理。官方镜像里其实内置了一份默认配置如果你不改配置直接启动会使用默认参数无密码、未开启AOF、RDB保存频率默认策略、日志输出到stdout。想要精细控制Redis的行为常规做法是把宿主机上的redis.conf挂载进容器。先把官方示例配置拉到宿主机mkdir -p /mydata/redis/conf wget https://raw.githubusercontent.com/redis/redis/7.0/redis.conf -O /mydata/redis/conf/redis.conf然后修改需要调整的配置项。我这里挑几个关键项说明bind 0.0.0.0 protected-mode yes port 6379 daemonize no requirepass your-strong-password appendonly yes appendfilename appendonly.aof dir /data maxmemory 1gb maxmemory-policy allkeys-lrubind 0.0.0.0表示监听所有网络接口容器内使用没问题因为宿主机端口映射的控制权在Docker手里。protected-mode yes配合密码使用安全上更严谨。daemonize no一定要保留容器场景下Redis必须以前台方式运行否则容器会立即退出。requirepass设置访问密码。appendonly yes开启AOF持久化这个选项在实际使用中比RDB更可靠。dir /data指定持久化文件的路径和数据卷挂载路径保持一致。启动命令跟上配置文件docker run -d --name my-redis \ -p 6379:6379 \ -v /mydata/redis/conf/redis.conf:/etc/redis/redis.conf \ -v /mydata/redis/data:/data \ redis:7.0 redis-server /etc/redis/redis.conf这里有个容易忽略的坑官方镜像默认的启动命令是redis-server如果你写了-v挂载了自定义配置文件必须在镜像名后面显式追加redis-server /etc/redis/redis.conf把自定义配置文件的路径作为参数传进去。如果只挂载配置而不追加命令容器依然会使用镜像内部的默认参数你改的redis.conf毫无意义。4.3 RDB和AOF怎么取舍Redis持久化主要有RDB快照和AOF日志两种方式。RDB是定期把内存里的数据直接生成一份二进制快照文件dump.rdb恢复速度快但是两个快照之间的数据有可能丢失。AOF是把每一条写操作以追加的方式记录到aof文件里数据安全性更高但是文件体积会膨胀恢复相对慢一些。我的建议是既要数据安全又不想丢失过多就开启AOF同时保留RDB。在上面的配置里appendonly yes已经开了AOF同时dir /data也允许Redis周期性写dump.rdb两个文件相互配合。生产环境里如果对数据丢失零容忍可以把appendfsync设置为everysec意思是一秒钟刷一次盘性能和数据安全性均衡。用docker attach或者直接看容器日志确认Redis启动完成。接下来向Redis写入几条数据再重启容器测试数据是否还在。重启测试命令docker restart my-redis docker exec -it my-redis redis-cli -a your-strong-password get hello输入密码后能正常返回之前写入的value就说明持久化配置彻底生效了。5. 图形界面与命令行双管齐下5.1 容器内外的redis-cli用法日常排查Redis问题redis-cli是绕不过去的工具。容器场景下有两种用法我经常混着用一种是直接用docker exec进容器内部执行。例如查看Redis的info信息docker exec -it my-redis redis-cli -a your-strong-password info memory另一种是把宿主机上也装一份redis-cli把容器内部的命令暴露出来。Ubuntu下可以用apt install redis-toolsCentOS则是yum install redis这样在宿主机上的操作路径更短比如redis-cli -h 127.0.0.1 -p 6379 -a your-strong-password ping还有几个排查频率很高的命令redis-cli monitor可以实时打印当前所有命令配置文件刚调完或者怀疑有异常写入时很好用redis-cli --latency可以看本机到Redis的延迟排查网络问题特别好用redis-cli -p 6379 info keyspace用来查看当前库中有多少个key观察业务是否写进了预期数据。这几个命令建议都自己敲一遍别光看着我写。5.2 可视化客户端怎么连命令行用久了总想用图形界面看一眼尤其看key的过期时间、内存分布、某个类型的value长什么样可视化工具确实方便。目前口碑最好的两个是Redis Desktop Manager和Another Redis Desktop Manager。RDM的优势是历史悠久、功能完整ARM是开源免费版界面清爽对中文支持也更好。我自己现在用的是ARM因为它支持Redis 6/7的ACL用户权限管理连新版本无缝连接。连接的时候有几个容易失败的点第一连接地址不应该填容器IP而是填宿主机地址因为在启动容器时已经做了端口映射容器内部的6379端口已经暴露到了宿主机的6379所以客户端指向localhost或者127.0.0.1就行。第二密码需要填启动容器时设置的requirepass。第三如果Redis版本比较新服务端增加了ACL用户那么客户端版本也要够新老版本协议兼容性差建议直接用最新版。一个完整连接参数示例地址127.0.0.1端口6379密码your-strong-password连接名称随意起。建好连接之后点测试连接能连通就说明一切正常。如果连接失败先回到命令行用redis-cli测一遍确认命令行通不通再排查图形化工具本身这种排查顺序可以帮你少走很多弯路。6. 进阶Compose编排、主从复制与分布式锁6.1 docker-compose一键部署Redis单实例的Docker run深入实践之后你会发现命令变得越来越长每次部署都要拼一堆-v、-p参数太容易出错。实际项目中我更推荐用docker-compose把Redis的启动编排固化下来。先准备一个docker-compose.yml文件把常用的Redis实例配置写进去services: redis: image: redis:7.0 container_name: my-redis restart: always ports: - 6379:6379 volumes: - /mydata/redis/conf/redis.conf:/etc/redis/redis.conf - /mydata/redis/data:/data command: redis-server /etc/redis/redis.conf然后在同一个目录下执行docker compose up -d整个Redis实例就按照声明式的配置跑起来了。以后要迁移到新机器只需要复制这个yaml文件和挂载的数据目录在新机器上再执行一遍docker compose up -d得到的就是完全一样的环境。这就是我在前面一直强调的环境一致性优势在生产交付中作用非常大。如果想再加一个端口不同的Redis实例比如6378端口只需要在compose文件里再加一个services节点改一下端口映射和容器名。这种方式比同时管理无数个docker run命令要清晰得多。6.2 主从复制的基础玩法单实例的Redis在开发和测试阶段够用一旦进入高并发或者数据兜底的场景主从复制就必须安排上。用Docker搭主从复制的思路很简单主节点负责写从节点负责读主节点自动把写操作同步给从节点。先准备两个配置文件分别命名为redis-master.conf和redis-slave.conf。主节点配置比较常规从节点必须加上一条关键的replicaof配置replicaof 192.168.1.100 6379注意从节点配置文件里的IP地址是提供主节点的宿主机IP在真实生产环境通常不是127.0.0.1。如果主从容器都跑在同一台Docker宿主机上还要特别注意网络模式问题。使用默认的bridge网络时容器间的互相访问不能直接用容器名连接因为跨容器网络没有DNS互通。更稳妥的做法是把两个容器放到同一个自定义网络里比如先创建一个网络docker network create redis-net再分别用--network redis-net参数启动主从容器这样从节点容器里可以像访问普通主机名一样直接使用主节点的容器名作为replicaof的地址。配置示例replicaof redis-master 6379启动之后可以进从节点容器执行info replication看到role:slavemaster_link_status:up就说明主从链路已经建立。这个场景我再补充一句真正生产级别的主从方案通常还要叠加Sentinel哨兵。哨兵本身也是一个独立的Redis进程负责监控主节点是否存活主节点挂了就自动把从节点提升为主节点。用Docker部署哨兵时最容易踩的坑是哨兵配置里宣告的IP地址要填宿主机可访问的地址否则客户端切换主从时会连到容器内部的IP导致连接失败。这块内容如果篇幅够展开就是一个完整的高可用方案这里只是起个头。6.3 分布式锁的正确用法聊到Redis的典型应用分布式锁绕不开。很多业务系统用Redis的SETNX命令模拟分布式锁。基础的加锁命令长这样SET lock_key unique_request_id NX EX 30NX保证只有key不存在时才能设置成功EX设置30秒自动过期避免锁永不释放。释放锁时不要直接DEL而是先GET比较value是否属于自己确认归属后再删除防止误删别人的锁。如果是通过Lua脚本实现原子性的比对删除可靠性会更高。用Docker部署Redis来验证分布式锁的逻辑非常方便因为可以快速起两个Redis容器模拟不同服务节点测试锁的互斥性。建议在实际项目中配合Redisson这样的客户端库它们对锁的自动续期、重试、公平锁等细节都有成熟实现尽量不要自己裸写SETNX生产上线问题特别多。在这里提到分布式锁主要是希望大家意识到Docker只是部署手段业务层怎么用好Redis才是真正需要学习的核心。7. 现场实录踩坑排查与修复7.1 容器启动失败的常见原因容器启动失败是最高频的故障。先分享一个我亲身经历过的典型案例执行docker run之后发现容器秒退docker ps看不到容器。第一反应是查看日志docker logs my-redis结果日志里只有一行“Cant open the log file: Permission denied”。排查出来的原因是挂载到容器里的redis.conf中配置了logfile /var/log/redis/redis.log但宿主机创建的这个日志目录没有给容器进程写入权限。解决办法是修改宿主机目录的所有者或者把logfile注释掉让日志输出到stdout再通过docker logs统一查看。如果你看到的是“Fatal error, cant open config file”十有八九是挂载配置文件时路径不对确认容器内的配置路径和启动命令里的路径一致。另一个常被忽略的问题是端口冲突。如果你先启动了一个mysql容器占用6379端口再启动Redis容器就会报“port is already allocated”。用docker ps查看当前正在使用的端口把端口换掉或者先停掉占用的容器问题就解决了。还有一层比较隐蔽的内核参数问题。Redis在启动时如果内存碎片整理和内核的overcommit策略不匹配会报“Memory overcommit must be enabled”。解决办法是在宿主机上执行sysctl -w vm.overcommit_memory1这个参数让内核允许Redis即便在内存虚高的情况下也能正常申请内存极端情况下可以降低Redis fork子进程时的失败概率。写完之后建议同时把vm.overcommit_memory1写入/etc/sysctl.conf重启机器以后参数也不会丢。这个问题在Docker容器里排查时会让人觉得莫名其妙其实是宿主机的内核参数影响了容器内的Redis进程这也是容器化部署的一个特点不是完全隔离底层内核依然共享。7.2 容器内外网络不通的排查思路网络问题排在所有Redis故障前列。报错格式千奇百怪无非是容器内能连、外部不能连或者另一个容器连不上。我的排查顺序和思路是这样的。先从宿主机出发测试端口通不通telnet 127.0.0.1 6379端口通了说明容器内的监听正常。如果连不上先用docker ps确认真实端口映射再检查防火墙规则。Linux上最常见的坑是ufw或firewalld拦住了6379端口。临时放开sudo ufw allow 6379/tcp生产环境建议在云安全组中限制来源IP而不是直接放通到公网。如果是容器之间的访问比如应用容器访问Redis容器遇到的问题往往不是端口映射而是容器网络隔离。我踩过最典型的坑是直接在应用容器里写localhost:6379去连Redis容器结果宿主机同网络模式下用localhost能通换成bridge网络模式就完全连不上了。正确做法是应用容器和Redis容器放到同一个自定义网络docker network create app-net里然后应用连接地址写成Redis容器的容器名。在自定义网络中容器名就相当于一个随IP变化而始终生效的DNS名字这个操作在Docker官方文档里有明确说明。总体来说先看防火墙再看网络模式再看容器名解析90%的网络问题都能在这个排查路径里找到答案。7.3 数据丢失、内存告警与日志定位数据丢失是Redis场景里最让人肉疼的问题。排查思路先确认持久化配置是否生效。在容器里执行docker exec -it my-redis redis-cli config get appendonly返回yes还是no一眼就知道问题出在哪。我在给朋友排查的时候发现他确实挂载了数据目录但是redis.conf里appendonly没开每次都生成的是RDB快照删除容器之后快照没有落地到宿主机目录自然就全部丢了。永久解决方式是把就是前面提到的开启AOF并把dir配置明确指向/data目录。内存告警问题也很常见。Redis容器跑着跑着宿主机内存飙升一做排查发现maxmemory没有设置进程会一直向系统申请内存直到把宿主机拖垮。生产环境务必在redis.conf里显式配置maxmemory比如maxmemory 1gb同时根据实际业务设置淘汰策略。Redis的淘汰策略不只有allkeys-lru一种如果业务场景要求某些key永不过期需要认真选择volatile-lru还是allkeys-lru这个选择直接影响业务稳定性。最后说日志定位。Docker环境下Redis容器的stdout实际就是宿主机上的docker日志查看方式用docker logs。日志过多时加-f实时跟踪排查问题时加--tail 100只看最近一百行这样输出不会把终端刷爆。日志定位的一个小规律是连接超时问题优先查网络权限和防火墙命令执行报错优先查Redis版本和配置项是否兼容内存异常优先查监控参数和key分布。这些排查顺序我在实际项目中反复用虽然没有银弹但大部分问题都能在十分钟之内定位。跑完这一整套Docker安装Redis的流程你会发现把Redis放到容器里并不是什么黑科技但它确实让环境管理这件事变得简单。你不需要再为版本冲突、编译过程、配置文件路径而折腾把精力集中在Redis本身的数据结构、性能调优、业务模型上这是我在实际实践中最直观的感受。如果你是一个刚接触容器的新人我的建议是先别急着复制我一长串的生产配置而是从最简单的docker run命令开始跑通再逐步加入数据卷、密码、自定义配置文件最后再上docker-compose和主从方案。一步一步在实践中建立手感比一次性把所有概念都塞进脑子要有效得多。我也希望你能在自己的服务器上把这篇内容里的命令都敲一遍尤其是那些让我记忆犹新的故障场景亲自踩过才会真正记得住。