资讯动态

Windows安装Redis全攻略:四种方案对比与踩坑经验

发布时间:2026/10/21 15:10:36 来源:尧图企业网站定制
很多人第一次在 Windows 平台安装 Redis第一反应是去官网找安装包翻一圈发现官网只给了 Linux 和 macOS 的下载入口Windows 用户直接被晾在一边。这不是错觉Redis 官方从一开始就没有原生支持 Windows 的计划。如果只是想在自己电脑上搭一个缓存服务或者让老项目能在本地跑起来其实办法很多只不过每个办法都有坑选错了后面全是眼泪。我这些年给不同项目装过很多次 Redis从临时测试到本地开发再到 Windows 上的长期运行都试过所以今天这篇就把 Windows 平台装 Redis 的几条主流路线、具体步骤和踩坑经验一次性说清楚。文章适合正在 Windows 上做开发的程序员、做测试的同学也适合只是想本地跑一个小型缓存的小白。我会尽量把每一步背后的原因讲明白这样你照着做的时候心里更有底。1. 为什么 Windows 平台安装 Redis 这么别扭1.1 Redis 官方为什么迟迟不出 Windows 版本Redis 内部高度依赖fork()系统调用来实现持久化主进程 fork 出子进程子进程负责把内存中的数据写成 RDB 快照或者重写 AOF 文件。这个机制在 Linux 上非常成熟但在 Windows 上并没有原生的 fork 支持。Windows 的进程模型和 Unix 完全不同虽然可以模拟出一个类似 fork 的效果但模拟出来的复制过程开销很大还容易造成进程不稳定。这是 Redis 官方不碰 Windows 的根本原因。另一个原因是事件模型差异。Redis 的事件循环在 Linux 上使用 epoll在 macOS 上使用 kqueue而 Windows 自己有一套 IO 完成端口模型也就是 IOCP。把 Redis 的异步事件逻辑从 epoll 移植到 IOCP工作量非常大而且改完之后很难保证和官方版本保持一致的行为。所以官方团队更愿意把精力放在 Linux 上对 Windows 的态度基本就是你要用就用容器别在裸 Windows 上折腾。1.2 对普通用户的实际影响因为官方没有 Windows 版网上流传的 Windows 安装包大多来自社区编译或者老版本的归档。用这些包不是不行但要时刻记住功能完整性和稳定性没有官方保障。Redis 3.0 时代有过一个社区维护的 Windows 移植版后来大家也一直在用但版本停在 3.0 就再没更新过。很多 Redis 4.0、5.0、6.0 甚至 7.0 引入的命令它根本不认识。如果你只是本地练手或者跑一个五分钟能验证完的 demo问题不大。但你要是想给团队搭一个长期运行的 Windows 服务就得认真考虑其他方案。后面我会把 Windows 下常见的几种安装方式都过一遍包括原生移植版、WSL2、Docker 和一个专门做 Redis 兼容的 Windows 原生服务这样你至少知道每种方式适合什么场景。2. 安装前先选型Windows 下跑 Redis 的几条主流路线2.1 多种方案横向对比Windows 平台跑 Redis 并不是只有一条路你可以根据当前需求选一个最合适的。为了让你一眼看明白差别我先把主流方案整理成一个表方案安装难度与官方 Redis 的一致性适合场景主要风险原生移植版低低版本停留在 3.0临时测试、快速跑通无官方支持稳定性差WSL2 安装官方版中高和 Linux 环境一致本地开发、学习占用系统资源环境切换有额外开销Docker 容器中高高同一镜像跨机器一致团队统一环境、CI、本地调试需要安装 Docker Desktop资源占用大Memurai低中高协议兼容Windows 原生服务、生产环境商业授权限制部分命令有差异2.2 不要一上来就敲命令先按需求选方案我见过很多人下载完安装包就直接双击结果不是启动失败就是安装后不会配置。我的建议是先把需求想清楚再决定走哪条路。如果只是为了临时跑一个缓存、复现一个 bug原生移植版最快五分钟就能启动。如果你每天都要写代码和 Redis 交互希望本地环境和线上 Linux 服务器保持一致那优先考虑 WSL2。项目已经容器化团队每个人都装了一套 Docker Compose 环境这种情况用 Docker 最省心。如果业务要求必须在 Windows 裸机上跑一个稳定的 Redis 服务不想开虚拟机也不想装 Docker那就认真评估一下 Memurai 这类原生兼容方案。不要所有项目都用同一种方式环境选错了后面排查问题的成本会非常高。3. 方案一Windows 原生移植版适合快速跑通3.1 下载、解压和目录说明这个版本的来源比较特殊实测下来最常用的是一个版本号为 3.0.504 的压缩包。压缩包一般分 32 位和 64 位两个目录如果你用的是 64 位 Windows直接进 64 位目录就对了。目录里常见的文件包括redis-server.exe、redis-cli.exe、redis-benchmark.exe、redis-check-aof.exe、redis-check-dump.exe以及redis.windows.conf和redis.windows-service.conf两个配置文件。下载完成后我建议把整个目录放到一个干净的路径下比如C:\Redis\路径名里不要有中文和空格。很多人后面注册 Windows 服务失败就出在路径上。还有一点要特别注意第三方打包的 exe 来源不明双击之前先用杀毒软件扫一下宁可多花三十秒也别图省事。3.2 命令行启动和常用参数启动这个版本不需要安装直接在命令行里进到解压目录运行redis-server.exe看到终端里打印出 Redis 的 ASCII 字符画和Running in standalone mode字样就说明启动成功了。默认监听 6379 端口绑定127.0.0.1没有密码。这时候再开一个终端窗口执行redis-cli.exe ping如果返回PONG客户端连接就没问题。如果你想换端口或者加密码可以不改配置文件直接带参数启动redis-server.exe --port 6380 --requirepass 你的密码这种方式适合临时验证。如果想让参数长期稳定生效更好的做法是把参数写进配置文件然后用配置文件启动redis-server.exe redis.windows.conf配置文件里需要改几个关键项后面我会专门讲。3.3 注册成 Windows 服务临时启动的问题是关掉终端 Redis 就停了电脑重启后还得手动打开。要是想让 Redis 一直以后台服务的方式运行可以把它注册成 Windows 服务。需要用管理员权限打开命令行然后执行redis-server.exe --service-install redis.windows.conf --service-name RedisDev执行成功后再启动这个服务net start RedisDev服务已经在运行后客户端能正常连上任务管理器里也能看到一个名为 RedisDev 的进程。如果之后不想用了先停止服务再卸载net stop RedisDev redis-server.exe --service-uninstall --service-name RedisDev这里有个小坑注册服务前一定要先确保手头没有正在运行的redis-server.exe进程。如果端口已经被占用服务注册后启动会报错。注册和卸载服务都需要管理员权限普通命令行窗口执行会提示拒绝访问。3.4 这个方案的实际体验这个旧版移植包我实际用过很长一段时间体验只能说凑合。最明显的问题是持久化执行BGSAVE时整个进程会卡住一小会儿在数据量稍大的时候非常难受。另外模拟 fork 的实现并不完善内存使用越大越不稳定32 位版本超过 3GB 左右甚至可能直接崩溃。还有一个致命点是命令兼容性。比如SET key value NX EX这种用法在 3.0 里还不完善项目里如果用了 Redis 5.0 之后才有的数据类型或命令这个版本会直接报unknown command。所以我现在只把它当成一个“快速试试 Redis 是什么”的入门工具不会让它承载正式项目逻辑。4. 方案二WSL2 安装 Redis开发首选4.1 开启 WSL2 环境如果你用的是较新版本的 Windows 10 或 Windows 11开启 WSL2 非常方便。以管理员身份打开 PowerShell执行wsl --install这个命令会帮你把 WSL 功能打开并安装一个默认的 Linux 发行版。执行完成后一般需要重启电脑。等待重启完成再打开 PowerShell 检查一下状况wsl -l -v如果看到的版本是 2说明 WSL2 已经就绪了。如果还是版本 1可以用下面的命令切换wsl --set-version 发行版名称 2我个人强烈建议你使用 WSL2 而不是 WSL1因为 WSL2 是真正的轻量虚拟机文件系统和 Linux 内核都更接近真实环境Redis 跑在里面遇到的行为也和生产环境更一致。4.2 在 Linux 子系统中安装 Redis进入 Linux 子系统后第一件事是更新软件源和已装软件sudo apt update sudo apt upgrade -y然后直接安装 Redissudo apt install redis-server -y安装完成后Redis 默认其实已经可以启动了。老版本发行版里默认是用 init 脚本管理新版本可能已经支持 systemd。先试着启动sudo systemctl enable redis-server sudo systemctl start redis-server如果你用的发行版不支持 systemd可以用传统方式启动sudo service redis-server start启动完成后验证redis-cli ping返回PONG就说明服务已经在子系统里正常跑起来了。4.3 修改配置与开机启动Redis 的配置文件路径一般是/etc/redis/redis.conf。默认配置里bind 127.0.0.1protected-mode yes。这个配置如果只在 WSL 内部使用没问题但你想从 Windows 宿主机连过去就要看情况了。如果只想让本机访问保持127.0.0.1就行Windows 会对 WSL2 做 localhost 转发你在 Windows 上用redis-cli -h 127.0.0.1 -p 6379就能连上。如果希望局域网其他机器也能访问那就得改配置bind 0.0.0.0 protected-mode no requirepass 你的强密码注意一旦你把 bind 改成0.0.0.0并且关闭 protected-mode就必须设置一个强密码否则 Redis 会暴露到局域网任何人都能访问你的数据。这是非常容易被忽略的安全风险。至于开机启动WSL 本身不会像 Windows 服务那样随系统一并启动子系统的所有服务。最稳的办法是在 Windows 侧创建一个计划任务在登录时执行wsl -d 发行版名称 -u root service redis-server start这样每次开机进入桌面后Redis 就会自动在 WSL 里运行。4.4 宿主机和 WSL 互联的注意事项WSL2 的网络结构是带虚拟机的Windows 宿主机和 WSL 之间通过虚拟网卡通信。Windows 上的 localhost 转发大多数时候能直接把 6379 转到 WSL但如果你发现连接超时不要死磕转发的概念先检查两边状态。我在实际使用中碰到过几次这种情况Windows 上redis-cli.exe -h 127.0.0.1 -p 6379连不上但 WSL 里redis-cli ping是正常的。最后一查基本就是 Redis 的bind设置成了127.0.0.1没有监听外部网卡。解决办法要么改成0.0.0.0并加密码要么用 WSL 的 IP 连接。WSL2 的 IP 每次重启可能都不一样所以尽量优先依赖 localhost 转发或者固定端口转发配置。5. 方案三Docker 容器运行 Redis干净可复现5.1 Docker Desktop 准备工作如果团队里已经统一使用容器那在 Windows 上装 Docker Desktop 是绕不开的一步。安装本身比较傻瓜主要注意安装完成后在 Settings 里把后端引擎切到 WSL2而不是传统 Hyper-V。使用 WSL2 后端的好处是启动更快资源占用也更可控。安装完成后打开终端验证docker version能显示 client 和 server 两段信息就说明 Docker 引擎已经跑起来了。如果只有 client 没有 server大概率是 Docker Desktop 没完全启动等它右下角图标变正常再试。如果你的电脑没有开启 BIOS 里的虚拟化功能Docker Desktop 启动会直接失败。这种情况要去 BIOS 设置里打开虚拟化或者检查 Windows 的虚拟化安全功能是否被其他软件占用。5.2 启动 Redis 容器先用命令拉取官方 Redis 镜像docker pull redis然后启动一个带密码、开启 AOF 持久化的 Redis 容器docker run -d --name redis-dev \ -p 6379:6379 \ -v D:/redis-data:/data \ redis \ redis-server --appendonly yes --requirepass 你的密码各参数说清楚-d表示后台运行--name redis-dev是容器名-p 6379:6379把容器内部的 6379 端口映射到宿主机 6379-v D:/redis-data:/data把 Windows 上的一个目录挂载进容器用来存放 Redis 的数据文件redis-server --appendonly yes --requirepass是容器启动后要执行的命令。启动完成后用下面命令验证redis-cli -p 6379 -a 你的密码 ping返回PONG就是正常的。容器的日常管理命令也很简单docker stop redis-dev docker start redis-dev docker logs redis-dev5.3 用 Docker Compose 管理更舒服命令行启动适合一次性操作项目里我更推荐用 Docker Compose 文件管理 Redis 容器。建一个docker-compose.ymlservices: redis: image: redis container_name: redis-dev ports: - 6379:6379 volumes: - ./redis-data:/data command: redis-server --appendonly yes --requirepass 你的密码 restart: unless-stopped然后在同目录执行docker compose up -d之后不管谁拉下这个项目只要装好 Docker Desktop执行同一条命令就能拉起一个配置完全一致的 Redis。这个好处在团队协作时特别明显再也不用担心每个人本地配置不一样导致问题无法复现。5.4 容器方式常见的坑Docker 方案最大的问题是资源占用。Docker Desktop 本身会占用不少内存如果电脑只有 8GB 内存再跑其他开发工具会非常吃紧。建议在 Docker Desktop 设置里调整内存上限不要让它无限制抢占。另一个坑是 Windows 路径挂载性能。把 Redis 的数据目录直接放在 Windows 磁盘上时AOF 写入性能明显不如在 Linux 原生环境里跑。如果只是本地测试这么用没问题如果追求性能还是让数据留在 WSL 的虚拟磁盘里更合理。还有一点官方 Redis 镜像本身是不支持通过环境变量REDIS_PASSWORD设置的必须用command参数或者挂载配置文件来传密码。我之前看到有人依赖这个环境变量结果容器起来后 Redis 根本没有密码还以为自己设置了这就是踩了镜像文档没细看的坑。6. 方案四Memurai 原生 Windows 服务面向生产6.1 安装流程Memurai 是一个专门面向 Windows 的 Redis 兼容实现不需要 WSL也不需要 Docker直接装成 Windows 原生服务。它实现的 Redis 协议和命令集覆盖面比较广对很多项目来说已经够用了。安装包下载下来后一路 Next 即可。安装过程中可以选择版本通常有个 Developer 免费版适合开发学习和测试。安装完成后Memurai 会以 Windows 服务的方式运行默认端口同样是 6379。你可以用标准服务命令控制它net start Memurai net stop Memurai配置文件语法和 Redis 的redis.conf很像常见的port、bind、requirepass、appendonly这些参数都能配置。对于必须把 Redis 跑在 Windows 原生环境里的场景这个方案会比旧版移植包靠谱很多。6.2 使用注意虽然 Memurai 是 Redis 兼容实现但它毕竟不是 Redis 官方分支不要默认它百分之百等价。我建议引入之前先在测试环境跑一遍项目的核心用例重点看字符串、哈希、列表、集合、有序集合这些数据类型的常用命令以及过期策略、淘汰策略、事务、Lua 脚本这些功能的兼容性。免费版一般有功能限制比如最大内存上限或者不支持某些高级特性商用场景需要购买授权。如果你们公司不想为了缓存引入额外的商业软件那还是回到 WSL2 或者 Docker 方案更稳妥。反过来如果局势要求 Windows 裸机部署不想多维护一层虚拟化Memurai 确实值得认真评估。7. 安装完成后的基础配置与验收7.1 推荐调整的配置项无论你用哪种方式安装有几项配置应该经常检查。打开 Redis 配置文件把下面这些内容根据实际情况调整好bind 0.0.0.0 protected-mode no port 6379 requirepass 你的强密码 maxmemory 256mb maxmemory-policy allkeys-lru appendonly yes appendfsync everysec save 900 1 save 300 10 save 60 10000bind 0.0.0.0表示允许外部网络访问但只建议在设置了requirepass的情况下开启。maxmemory 256mb是为了防止 Redis 无限制吞掉内存本地开发时可以根据电脑配置调整。maxmemory-policy allkeys-lru是内存满后按最近最少使用算法淘汰数据适合缓存场景。appendonly yes和appendfsync everysec是开启 AOF 持久化并把 fsync 策略设为每秒一次兼顾性能和安全性。save配置是 RDB 快照触发条件只要你在 900 秒内改了 1 次数据就会触发一次快照。这些配置不是越多越好而是要根据实际项目需求决定。比如你的数据允许丢失一分钟那 AOF 可以关掉减少磁盘写入压力。比如你的场景本身没有淘汰需求那就不该设置allkeys-lru否则缓存数据会莫名其妙消失。7.2 安装后的常规验证配置改完后我习惯按顺序做几个验证确保 Redis 真正能用了。先用redis-cli ping确认连接正常然后执行redis-cli set hello world redis-cli get hello能正确写入和读取基本功能就没问题。接着验证持久化执行redis-cli shutdown重启 Redis再get hello如果值还在说明 RDB 或 AOF 持久化已经生效。如果需要简单压测可以用自带工具redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 10000这行命令表示用 100 个并发连接执行 10000 次请求输出里的 Requests per second 能帮你直观判断当前环境的吞吐量。最后再用redis-cli info stats看连接数和命令执行统计确认没有异常飙升或大量失败。8. 常见问题与排查技巧实录8.1 端口被占用了怎么办Redis 默认端口 6379很多开发工具都会占用到。如果你启动 Redis 时发现端口被占用先看看到底是谁在占用netstat -ano | findstr 6379输出里的最后一列是 PID再用tasklist查这个 PID 对应哪个进程tasklist | findstr 该PID如果是其他软件占用了 6379两个选择改 Redis 端口到 6380或者把占用进程关掉。改端口只需要在配置文件里把port 6379改成port 6380客户端连接时指定-p 6380即可。8.2 Windows 下 Redis 启动后闪退怎么办旧版移植包和环境变量配置不当最容易出现启动后一闪而过。双击 exe 启动时窗口消失你根本看不到错误信息。正确做法是用命令行启动redis-server.exe redis.windows.conf这样错误信息会留在终端里比如配置文件路径不对、requirepass语法错误、目录没有写权限。如果是注册服务后启动失败要去 Windows 事件查看器里找到 Redis 对应服务项的日志里面通常会记录原因。还有一个容易踩的点64 位系统运行 32 位版本或者反过来。检查压缩包里的目录确保你用的是和操作系统位数匹配的 exe。8.3 WSL2 里 Redis 从 Windows 宿主机连不上WSL 内部redis-cli ping正常但 Windows 上redis-cli -h 127.0.0.1 -p 6379连接不上这个问题我见过太多次了。优先检查/etc/redis/redis.conf里的bind和protected-mode。很多时候 Redis 只监听了127.0.0.1等于只允许 WSL 自己访问。改成bind 0.0.0.0并设置密码后宿主机连接基本就能通。如果配置没问题但是依然连不上再看 Windows 防火墙是否拦了 6379 端口。部分 Windows 安全软件也会拦截 WSL 虚拟网卡的回环转发这种情况需要在防火墙放行规则中增加 WSL 对应的流量。8.4 Docker 容器重启后数据丢失如果你在docker run时没有挂载数据卷容器一旦被删除里面的 Redis 数据就全部丢了。一定要在启动时加-v D:/redis-data:/data这样 Redis 的数据文件会持久化到 Windows 磁盘。如果你用 Docker Compose确保volumes里挂载了宿主机目录。重启容器时不要直接docker rm再重新docker run优先使用docker restart redis-dev避免误删容器。8.5 持久化失败AOF 文件写不进去出现持久化失败时第一反应不是去改 Redis 配置而是看磁盘权限和空间。Windows 目录挂载进容器后容器内进程可能没有写权限。用docker logs redis-dev能看到明确报错比如Cant open the append-only file: Permission denied。本地原生版则要注意目录是否放在需要管理员权限的系统目录下。Redis 进程以普通用户运行时没有权限在C:\Program Files下写数据文件。解决办法就是给 Redis 目录设置一个专门的可写权限或者把数据目录放到用户目录下。8.6 内存配置不当导致 Redis 被淘汰得很快maxmemory设置得太小同时使用的数据量又大Redis 会按maxmemory-policy一直淘汰 key。表面上是数据丢失实际上是被淘汰策略清理了。如果你发现数据频繁消失先用redis-cli info memory查看当前内存使用再看 maxmemory 是否合理。缓存场景使用allkeys-lru是合理的如果是需要保证数据不能丢的场景这个配置会让 Redis 变得非常危险。9. 我的实操体会说了这么多最后分享一点我自己的使用习惯。日常在 Windows 上做开发时我更偏向用 WSL2 跑 Redis因为项目最终要部署到 Linux 环境本地用 WSL2 可以最大程度保证命令、持久化行为和生产环境一致。旧版移植包虽然快但版本停留在 3.0很多新特性、新命令在本地测不出来上了生产才发现问题就很尴尬。Docker 方案我也经常用特别是团队协作时一个 Compose 文件就能让所有人拉起一模一样的 Redis 环境。唯一让我犹豫的是资源占用开发机内存紧张的时候开一个 Docker Desktop 实在肉疼所以看你自己的电脑配置来定。如果你只是临时做一个简单的排行榜、分布式锁 demo原生移植版真的够了没必要为了跑一个 Redis 再装一堆环境。但千万别把旧版移植包直接搬到生产 Windows 服务上长期跑真出了问题凌晨爬起来看日志的人大概率是你。最后再提醒一句无论选了哪种方式配置文件里的bind和requirepass一定要花十分钟认真看一遍Redis 空密码暴露在局域网里相当于给外人开了一扇门这个后果无论如何不值得冒。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑