Windows 上用 Docker Desktop 安装配置 Redis 的完整指南

我先把这套操作过一遍，再把过程中最容易翻车的几个环节单独拎出来讲透。如果你已经在用 Docker Desktop，可能只是差点开 Redis 就收工了；但如果你是在 Windows 上从头装 Docker Desktop 再跑 Redis，那中间的坑多了去了——比如虚拟化没开启、WSL 2 内核没更新、容器数据一重启就丢。这篇文章会把这些全部覆盖到，你可以直接照着操作。

1. 为什么推荐用 Docker Desktop 跑 Redis，而不是直接在 Windows 装

先回答一个很多人问过的问题：我明明能下载 Redis 的 Windows 安装包，为什么非要折腾 Docker Desktop？答案很简单——官方不支持 Windows 版 Redis。Redis 的官网和源码仓库从来没有提供过 Windows 原生版本，你在网上搜到的“Redis Windows 安装包”基本都是第三方团队维护的移植版，版本滞后不说，性能和稳定性也跟官方版有差距。

而 Mac 和 Linux 用户没有这个烦恼，所以如果你在 Windows 上做开发，Docker Desktop 几乎是跑 Redis 的最优解。另外几个实际的理由：

• 版本切换成本极低。项目里 Redis 版本要求不一样，或者你想试试最新版，用 Docker 就是改一行镜像标签的事，不需要卸载重装。
• 环境隔离干净。不用往系统里塞一堆依赖，卸载也简单：容器删掉、镜像删掉，系统里不留痕迹。
• 配置和数据和项目一起走。你可以把 redis.conf、数据目录通过挂载的方式管理起来，整个 Redis 环境能跟随项目代码一起提交，换电脑一键拉起来。

注意：Docker Desktop 本身是商业软件，大公司商业用途需要付费授权，个人开发和小团队免费够用。这点一直有争议，但抛开授权因素，它在开发环境里的便利性确实没话说。

2. 先把 Docker Desktop 装好：Windows 上最容易被卡住的环节

没装过 Docker Desktop 的读者，建议把这一节看完再动手。我见过太多人在这一步就卡住，后面只能干瞪眼。

2.1 安装前的系统检查

Docker Desktop 在 Windows 上依赖 WSL 2 或 Hyper-V 后端。比较推荐的是 WSL 2，因为它内存占用更少，启动速度也更快。安装前先确认两件事：

1. Windows 10 版本需要 2004 及以上，或者 Windows 11。老版本的 Windows 10 跑 WSL 2 会遇到内核安装失败的问题。
2. 在任务管理器 -> 性能选项卡里确认虚拟化显示为“已启用”。如果显示“已禁用”，需要进入 BIOS/UEFI 开启 Intel VT-x 或 AMD-V。

这两项缺一不可，很多人装完 Docker Desktop 后启动报错 Docker Desktop failed to start because virtualisation support wasn't detected，十有八九就是这两个检查没过。

2.2 安装步骤

1. 启用 WSL 功能。用管理员身份打开 PowerShell，执行：

powershell复制wsl --install

这条命令会同时启用 WSL 功能和“虚拟机平台”功能，并默认安装 Ubuntu。执行完成后系统会要求重启，先别急着装 Docker，重启完再说。

提示：如果你已经装了 WSL 但版本是 1.x，需要用命令升级到 2.x。wsl --set-version <发行版名称> 2 能把指定的 Linux 发行版从 WSL 1 迁到 WSL 2。

2. 下载并安装 Docker Desktop Installer。安装过程中如果弹窗询问使用 WSL 2 还是 Hyper-V，选 WSL 2。这一步在最新的安装包里可以直接勾选，老版本需要在设置里手动切。
3. 安装完成后启动 Docker Desktop，等右下角鲸鱼图标变成稳定状态（不再转圈），说明 Docker 引擎已经正常跑起来了。
4. 打开命令行工具，输入 docker version 验证安装。能看到 Client 和 Server 两段信息就说明搞定了。如果只有 Client 没有 Server，说明 Docker 引擎没起来，回到上一步检查虚拟化设置。

2.3 Docker Desktop 启动失败排查清单

启动报错的概率不低，整理一张排查表，你按顺序走一遍：

3. 拉取并启动 Redis 容器：简单模式和带配置模式

Docker Desktop 装好之后，正式进入 Redis 安装环节。这里分两个层级去讲，第一级是跑通，第二级是正经用。

3.1 简单模式：一条命令跑起来

打开任意命令行（PowerShell、CMD 或 VS Code 终端都行），执行：

bash复制docker run -d --name my-redis -p 6379:6379 redis:7-alpine

解释一下这条命令：

• docker run：创建并启动一个新容器。
• -d：后台运行，输出不占用当前终端。
• --name my-redis：给容器起名，后续管理都靠这个名称。
• -p 6379:6379：把宿主机（也就是你电脑）的 6379 端口映射到容器内的 6379 端口。这样你本机的 Redis 客户端才能连上容器里的 Redis。
• redis:7-alpine：镜像名和标签。7-alpine 表示 Redis 7.x 版本的 Alpine Linux 精简镜像，体积小、启动快。

执行完后，用 docker ps 查看容器是否运行。状态是 Up 就成功了。然后可以测试连通性：

bash复制docker exec -it my-redis redis-cli ping

返回 PONG 就说明 Redis 正在正常运行。

3.2 进阶模式：挂载配置文件和数据卷

跑通只是第一步。如果你只是临时用一下，3.1 就够了。但真实项目里，Redis 通常需要修改 maxmemory、启用持久化、设置密码等，这时候就需要指定配置文件并挂载数据目录。

推荐先拉取一个 Redis 镜像，再把容器里的默认配置拷贝出来改：

bash复制docker run -d --name redis-temp redis:7-alpine

# 把容器内的默认 redis.conf 拷贝到当前目录
docker cp redis-temp:/etc/redis/redis.conf ./redis.conf

# 顺便把存数据的目录也建好
mkdir -p ./redis-data

# 删掉临时容器
docker rm -f redis-temp

接着编辑 redis.conf，至少要关注这几个配置项：

conf复制# 开启远程访问（容器里必须有这个，否则外部连不上）
bind 0.0.0.0

# 关闭保护模式
protected-mode no

# 设置密码（生产环境强烈建议）
requirepass yourpassword

# 启用 AOF 持久化
appendonly yes

# 数据目录（容器内路径）
dir /data

这里必须解释一下 bind 0.0.0.0 和 protected-mode no：Redis 的安全默认值是只允许本机访问，但容器是个独立的网络命名空间，如果你不这样配置，宿主机和外部客户端永远连不进去。这两个配置只应该在可信内网或开发环境使用，生产环境千万靠密码和防火墙兜底。

然后正式启动一个挂载了配置和数据的容器：

bash复制docker run -d \
  --name redis-server \
  -p 6379:6379 \
  -v $(pwd)/redis.conf:/etc/redis/redis.conf \
  -v $(pwd)/redis-data:/data \
  redis:7-alpine \
  redis-server /etc/redis/redis.conf

上面命令里的 -v 参数就是挂载：宿主机当前目录下的 redis.conf 映射到容器内的 /etc/redis/redis.conf，宿主机上的 redis-data 目录对应容器里的 /data。以后数据都写在宿主机磁盘上，容器删了重建也不丢。

验证一下配置是否生效：

bash复制docker exec -it redis-server redis-cli -a yourpassword ping

能返回 PONG，说明密码和连接都正常。

3.3 镜像选型和 tag 的选择

不少人会在这里纠结：redis、redis:alpine、redis:7.2、redis:7.2-alpine 到底选哪个？我的建议很简单：

早期我贪图方便全用 alpine，后面在一个需要 Lua 脚本和复杂模块的环境里踩到坑，才发现 Debian 系的官方镜像更省心。本地调试用 alpine 没问题，部署到服务器之前换成 Debian 系的稳定版，是成本最低的保险行为。

4. 操作 Redis：连接、配置检查与数据验证

Redis 跑起来后，下一步是确认它工作正常，并且你能熟练地用它调试问题。

4.1 进入容器还是从宿主机连接

连 Redis 有两条路：

• docker exec -it redis-server redis-cli：进入容器内部再敲命令，适合容器里没有加载外部密码配置时快速验证。
• 宿主机装一个 Redis Desktop Manager / Another Redis Desktop Manager，通过 127.0.0.1:6379 连接：适合日常开发和查看键值。

推荐后一种方式。平时写代码调试时效率会高不少，可视化的键值浏览对排查问题也远比黑框框方便。后面第五节我会专门展开讲客户端选型。

4.2 基础操作验证

在命令行或者客户端里执行下面几组命令，确认 Redis 的数据读写、过期策略和持久化都正常：

bash复制# 设置一个键
set user:name "zhangsan"

# 获取键
get user:name

# 设置带过期时间的键（10秒后自动删除）
set session:token "abc123" ex 10

# 查看所有键（生产环境慎用，键多时会卡）
keys *

# 查看 Redis 信息
info

特别注意 keys * 这个命令：它在键特别多的时候会阻塞 Redis 主线程。如果你在排查线上问题，建议用 scan 0 代替，这是不少人后续要去补的课。

4.3 持久化效果验证

这是我最想让读者动手做的一个实验，因为它能让你直观理解 Docker 挂载数据的价值：

1. 在 Redis 里写入几个键值。
2. 执行 docker restart redis-server 把容器重启。
3. 重启后检查键值还在不在。

如果配置里开了 appendonly yes，数据应该完整保留。如果你用 3.1 的简单模式启动，没挂载任何数据目录，也没改持久化配置，容器删掉后数据全丢，这也印证了前面的结论：临时玩玩可以这么搞，正经用必须挂载数据卷。

再进一步，把容器删了：

bash复制docker rm -f redis-server
docker run -d \
  --name redis-server \
  -p 6379:6379 \
  -v $(pwd)/redis.conf:/etc/redis/redis.conf \
  -v $(pwd)/redis-data:/data \
  redis:7-alpine \
  redis-server /etc/redis/redis.conf

数据还在，因为 AOF 文件留在宿主机目录下。这一步走通后，你就真正理解了容器复用数据的思路。

5. 可视化客户端怎么选：不只是 Redis Desktop Manager

很多人接触 Redis 的第一件事就是找一个可视化客户端，因为黑框框命令行在 Windows 下体验确实不够亲切。这里聊聊主流选择，帮你避坑。

5.1 几款常见客户端对比

5.2 推荐的组合打法

日常开发我会装一个 Another Redis Desktop Manager 当主力，看图查键、编辑过期时间都很顺手。真到了要分析内存碎片、看大键分布、排查慢查询的时候，命令行配合 Redis Insight 会更专业。

关于安装包：直接从各自的 GitHub Releases 页面或官网下载就行，不要从第三方下载站拿安装包，国内第三方下载站的捆绑和篡改问题太严重了。由于网络环境的不同，如果打不开官方下载地址，就用其他合法渠道，找人拷贝一份官方安装包也行。

6. 踩过的坑：容器里 Redis 连不上、启动失败与数据丢失的完整排查过程

每个环节都顺畅是不可能的，下面把自己反复踩过的三个典型问题的排查链路记录下来。

6.1 问题一：应用连不上 Redis，报 Connection Refused

现象：宿主机某个 Java 或 Node.js 应用去连 localhost:6379 报拒绝连接，但 docker ps 显示容器明明在跑。

排查链路：

1. 先在宿主机测试端口是否通：telnet 127.0.0.1 6379。如果不通，看第2步。
2. 确认端口映射：docker port redis-server，输出应该是 6379/tcp -> 0.0.0.0:6379。如果这里空白的，说明 -p 参数没配对。
3. 进入容器测试 Redis 本身是否正常：docker exec -it redis-server redis-cli ping。如果正常，问题基本锁定在端口映射或配置文件里的 bind 设置。
4. 检查 redis.conf 的 bind 字段——大部分问题都出在这里。默认值是 127.0.0.1，这会让 Redis 只监听容器内部的回环地址，宿主机当然连不上。改成 0.0.0.0 后重启容器，连接恢复正常。

教训：Docker 端口映射容易给人一种错觉，以为映射了就万事大吉。实际上容器内的服务还必须监听在对外可见的网卡上，bind 127.0.0.1 的服务在容器场景里几乎等于没有服务。

6.2 问题二：Redis 容器反复重启，日志报权限错误

现象：用挂载目录的方式启动 Redis 后，容器启动几秒就退出，docker logs 里出现 Can't open the log file: Permission denied 或者 Failed opening the RDB file。

排查链路：

1. 查看完整日志：docker logs redis-server。发现 Redis 进程在写 dir 配置指定的目录时没有权限。
2. 确认宿主机目录权限：ls -ld ./redis-data。如果属主不是当前用户，就会出现访问问题。
3. Windows 上挂载目录给 Linux 容器时，权限模型不同于纯 Linux 环境。最简单的处理方式：给挂载目录的权限放开，或直接确保目录当前用户可用。

bash复制chmod -R 777 ./redis-data

4. 重启容器验证恢复。

教训：Windows 上跑 Docker 最容易忽略的就是文件权限模型。它不像 Linux 下直接 chown redis:redis 那么清晰，很多问题会绕弯。给 redis-data 可写权限是最快路径，但也别真拿 777 去线上环境用，这里仅仅是开发机的取舍。

6.3 问题三：容器内数据全丢

现象：Redis 里几千个键，某个时间节点后全变成空的。检查后发现是容器被重建了，而数据没挂载到宿主机。

排查链路：

1. docker inspect redis-server 查看 Mounts 一栏，里面列出的挂载点如果为空，说明当初启动时根本没配 -v。
2. 检查当前容器是不是原来的容器：docker ps -a 能看到多个名称相同但 ID 不同的容器，大概率中间有人执行过 docker rm。
3. 在没有数据卷挂载的情况下，容器删除会把整个可写层一起删除，Redis 的数据（RDB/AOF 文件）保存在容器内的 /data 目录，文件随着容器一起销毁了。

教训：很多初学者只记住了 Docker 的方便，却忽略了一个本质——容器是“一次性”的，你不会去更新一个容器里的配置，而是直接删掉它重建一个。数据必须放在容器之外，使用 -v 挂载或 named volume 管理。这就是为什么上面第 3 节里，我特别强调从一开始就要挂载数据目录。

7. Redis 核心配置与容器环境的配合

如果只是安装，这篇文章到这里就能收尾了。但 Redis 装完之后到底该怎么配，常常是开发者的盲区。这里把容器环境里最关键的几项配置拿出来说说。

7.1 关键配置速查表

容器里跑 Redis，最大的不同在一个底层逻辑里：Redis 本身对容器的资源限制感知能力很弱，它不会因为你给容器分配了 1GB 内存就自动限制自己到 1GB 以内。所以 maxmemory 必须显式配置，否则 redis-server 会把容器可用的宿主机内存吃穿。

7.2 为什么建议开 AOF

Redis 有两种持久化机制：RDB 快照和 AOF 日志。实际项目里可以配合使用。

RDB 是每隔一段时间生成一个二进制快照，恢复速度快，但两次快照之间的数据会丢。AOF 是追加写命令日志，可以做到“最多丢 1 秒数据”，缺点是对性能和磁盘空间有一定影响，恢复比 RDB 慢。

开发环境里开 AOF 几乎没成本，所以我建议直接 appendonly yes。配置里更细的参数 appendfsync everysec 是默认值，兼顾了数据安全和性能，普通场景不用再改。

7.3 关于两套持久化机制的一个辩证看法

网上有一种说法是“只开 RDB 就行，AOF 文件太大”。这个说法并不全对——AOF 文件确实会膨胀，但 Redis 有 BGREWRITEAOF 自动重写机制，可以在后台压缩 AOF 文件。生产实践更常见的做法是 RDB 和 AOF 同时开，Redis 重启时会优先用 AOF 恢复数据，因为它的数据更完整。

下面是一个配置片段，可以直接挂载使用：

conf复制bind 0.0.0.0
protected-mode yes
requirepass Redis@2024!Secure
appendonly yes
appendfsync everysec
maxmemory 512mb
maxmemory-policy allkeys-lru
save 900 1
save 300 10
save 60 10000

这份配置里 protected-mode yes 和 requirepass 同时存在，保证即使绑定了所有网卡，也不至于完全裸奔——这也是我在生产环境里推荐的标准姿势。

8. 用 docker-compose 把 Redis 跑成标准服务

真实项目里，没人会每次都敲一长串 docker run。推荐直接用 docker-compose 把 Redis 定义成项目的一部分。

在项目根目录创建一个 docker-compose.yml：

yaml复制services:
  redis:
    image: redis:7-alpine
    container_name: project-redis
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis/conf/redis.conf:/etc/redis/redis.conf
      - ./redis/data:/data
    command: redis-server /etc/redis/redis.conf
    environment:
      - TZ=Asia/Shanghai
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "yourpassword", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5

在 docker-compose.yml 所在目录执行：

bash复制docker compose up -d

查看服务状态：

bash复制docker compose ps

我比较喜欢 healthcheck 的配置：它会定期用 redis-cli ping 探测 Redis 的健康状态，之后对接容器编排或做依赖检查都非常方便。

需要装一个 Redis 作为依赖但不能用完整 docker-compose 的简单项目也可以只跑单容器，但不管怎样，把 Redis 的配置数据目录上升到“项目资产”的层面来看，比随机散落在某次命令行参数里要可靠太多。

9. 主从复制和哨兵的容器化部署思路

最后扩展一个方向：有些读者搜到这里的目的是搭 Redis 主从或哨兵集群，简要说一下思路，细节务必查官方文档再动手。

主从复制的最小配置：两个 Redis 容器，一个当主节点，一个当从节点，从节点配置里加一行：

conf复制replicaof <主节点IP> 6379

容器之间要用自定义网络，并且从节点必须通过容器名或自定义网络别名访问主节点。

创建网络：

bash复制docker network create redis-net

主节点容器：

bash复制docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7-alpine

从节点容器：

bash复制docker run -d --name redis-slave --network redis-net -p 6380:6379 redis:7-alpine redis-server --replicaof redis-master 6379

哨兵模式则至少需要 3 个哨兵容器才能正确判定客观下线。在生产环境，建议直接用 Redis 官方推荐的 Redis Sentinel 或 Redis Cluster 方案，不要凭感觉配。这一步扯到分布式系统的高可用边界，需要另外一篇文章的篇幅去展开。

最后说一句个人感触：Docker Desktop 装 Redis 这件事，看着简单，但很多人的认知止步于“容器起来了，Redis 通了”，对数据持久化、网络模型和配置管理没深究。真正想在开发环境里长期省心，建议把挂载、配置文件和 compose 组织方式一次性学好，后面从“本地开发”跨越到“预发布环境”时就会顺畅得多。