Windows 10 下 Redis 安装指南：版本选择、服务注册与配置排查

上周帮同事在一台刚装好的 Windows 10 机器上折腾 Redis，他光是找安装包就花了一下午：官网翻遍了没有 Windows 版下载入口，网上搜到的教程一半停留在 2016 年那个微软版 3.2，另一半直接甩一句“上 Docker 吧”就没了下文。其实 Windows10 安装 Redis 这件事本身并不复杂，坑都藏在“版本怎么选”“服务怎么注册”“配置文件改哪几行”“连不上往哪查”这四个环节里。这篇就把完整流程走一遍——从下载解压、前台启动、注册成系统服务，到配置文件逐项拆解和常见报错排查。不管你是本地跑个 Redis 练数据类型，还是想给自己的 Django、Spring Boot 项目挂一个本地缓存，照着做完就能用。因为没法在文章里贴图，我会把每一步执行后终端上应该出现的输出原样贴出来，你屏幕上的内容对得上，就说明这一步过了。

1. 动手之前先搞清楚：Windows 10 上的 Redis 到底从哪来

1.1 官方不发布 Windows 安装包这件事的来龙去脉

Redis 官方仓库一直把 Linux/Unix 系作为第一支持平台，核心代码里大量依赖fork、epoll、写时复制这些 Unix 才有的机制，官方从未发布过 Windows 原生安装包。你现在在网上能搜到的“Windows 版 Redis”，本质上有三类来源：一类是早年微软开放技术团队做的移植版，停在 Redis 3.2.100 就归档了；一类是社区开发者在这个移植版基础上继续跟进，目前维护得比较勤的是 5.0.14.1 这个版本；最后一类是完全重写的商业兼容实现，比如 Memurai，它按 Windows 服务的方式重新实现了一遍，协议兼容但内核不是同一套。

这个背景决定了后面所有选择。你选 3.2.100，等于放弃了 Stream 类型、放弃了 4.0 引入的模块系统和UNLINK、SWAPDB这类命令，一些新版客户端库甚至可能握手失败。你选 5.0.14.1，日常开发、缓存、队列、简单分布式锁这些场景基本都够，缺的是 6.0 之后的多线程 IO 和 ACL 细分权限。所以第一步不是急着下载，而是先确认：你的项目代码里用没用 6.0 以上的命令或客户端特性。用了，就老老实实走 WSL2 或者 Docker 那条路。

1.2 五条路线的横向对比

我把常见的几种做法摆在一起，你可以直接对照自己的场景挑。

表格里“安装难度”这一列是我自己按同事上手的实际耗时打的。社区维护版之所以标“低”，是因为它就是个压缩包，解压、改两行配置、双击启动，五分钟能跑起来。Docker 那条路标“中”，卡点不在 Redis 本身，而在 Docker Desktop 对 Windows 版本和虚拟化功能的要求上——Windows 10 家庭版需要走 WSL2 后端，而老版本 1809 以下的系统还得先升级。

1.3 我为什么还是推荐大多数本地开发者用解压版

先说结论：如果你只是想在自己电脑上有个 Redis 用，社区维护的 5.0.14.1 解压版是性价比最高的选择。理由是它的路径依赖最小——不需要装虚拟机、不需要开 Hyper-V、不需要占几百兆内存跑一个容器运行时，一个几十兆的文件夹丢在哪都能跑。进程管理走的是 Windows 原生服务，任务管理器里能直接看到，出问题了看日志文件就行。

WSL2 那条路我也用过一段时间，好处是命令和行为跟生产环境几乎一致，坏处是网络这层多了一次地址转换，Windows 侧的客户端连 WSL 里的 Redis 偶尔会因为localhost转发失效而连不上，排查起来比原生版麻烦。Docker 更适合你已经习惯了容器工作流的情况，或者需要一次性起主从、哨兵做实验的场景。选哪条不重要，重要的是知道自己为什么选它。

2. 安装包从哪来：版本选择、下载与目录规划

2.1 3.2.100 和 5.0.14.1 到底差在哪

这两个版本号经常被混着推荐，我把实际差别列一下。3.2.100 是微软归档版本，压缩包里带的还是redis.windows.conf这套配置体系，命令集停在没有GEO系列、没有PFADD之外的 HyperLogLog 命令增强、没有MEMORY USAGE这些诊断命令的阶段。5.0.14.1 补上了 Stream 类型、CLIENT ID、CLIENT UNBLOCK、UNLINK、MEMORY DOCTOR等一批实用命令，配置文件里多了lazyfree相关的开关，更适合拿来做缓存治理这类需要观察内存和异步删除的实验。

有个细节容易被忽略：5.0.14.1 这套二进制是基于 5.0 分支的稳定版做的，它和 6.0/7.x 的客户端库不完全对等。比如某些语言的客户端在建立连接时会发送HELLO命令做协议协商，这个命令是 6.0 才有的，碰上就会报ERR unknown command。真遇到了，要么把客户端降到兼容模式，要么换 WSL2 装 6.0 以上。我个人的做法是：Python 用 redis-py 的老一点版本没问题，Node 侧用 ioredis 记得关掉enableAutoPipelining之外的新特性探测。

2.2 下载与解压：路径这件事比你想的重要

下载渠道上，建议认准 GitHub 上的发布页，找Redis-x64-5.0.14.1.zip这个包。别去各种下载站点的“高速下载”，那些包经常被塞了别的运行时或者改过配置文件默认值，出问题你根本查不出来。

解压路径有讲究，我踩过的坑分享两条。第一，不要放在C:\Program Files下面。这个目录对普通用户进程有写入限制，Redis 默认会把dump.rdb、appendonly.aof和日志文件写在当前工作目录下，权限一拦，服务启动就会直接退出，日志里只有一句含糊的写入失败。第二，路径里不要带中文和空格。虽然 Windows 的文件系统支持，但 Redis 解析配置文件里的dir参数时对空格转义处理得并不好，路径里出现空格经常表现为“配置看起来没错，但数据文件就是没生成”。

我的习惯是统一放在D:\redis\5.0.14.1\这种纯英文、无空格的短路径下。目录结构大概是：根目录放redis-server.exe、redis-cli.exe、redis-benchmark.exe这些可执行文件，再建一个data子目录专门放数据文件和日志，配置里把dir指到./data。这样以后要删库重来，直接删data目录就行，不会误伤可执行文件。

2.3 解压完先别急着双击，做三件事

第一件，确认压缩包里的redis.windows.conf和redis.windows-service.conf都在。前者是前台运行用的，后者是注册服务用的模板，两者默认配置不完全一样，比如服务版默认把logfile设成了一个具体文件名，前台版默认输出到控制台。很多人注册完服务发现没有日志，就是因为混用了两个文件。

第二件，打开命令行确认能执行。在解压目录的地址栏输入cmd回车，然后敲：

redis-server.exe --version

正常会打印一行版本信息。如果提示“不是内部或外部命令”，那是你把命令行开在了别的目录，或者文件名打错了——注意 Windows 下这堆可执行文件都带.exe后缀，网上很多 Linux 教程里的redis-server在这里直接敲会失败。

第三件，看看有没有别的程序占着 6379。在命令行里跑：

netstat -ano | findstr :6379

没有任何输出，说明端口空着，可以往下走。有输出的话，把最后一列的 PID 记下来，用tasklist /FI "PID eq 那个PID"查出是谁占的，先处理掉再装，否则后面服务注册成功但起不来的问题会让你怀疑人生。

3. 从命令行前台启动到注册成 Windows 服务

3.1 先在前台把它跑起来，确认没问题再谈服务

注册服务之前一定要先在前台跑通一次，这一步省不得。前台运行能看到完整启动日志，配置里哪一行写错了、哪个端口不通，终端上会直接告诉你。

cd /d D:\redis\5.0.14.1 redis-server.exe redis.windows.conf

回车之后，终端应该会打印一大段启动横幅，包含版本号、PID、端口 6379，最后一行是Ready to accept connections。看到这行就说明服务起来了，这个窗口别关，另开一个命令行窗口连上去验证：

redis-cli.exe -h 127.0.0.1 -p 6379

进入交互界面后敲ping，返回PONG就通了。到这里你可以顺手把几条基础命令跑一遍，确认读写正常：

127.0.0.1:6379> set hello world OK 127.0.0.1:6379> get hello "world" 127.0.0.1:6379> del hello (integer) 1 127.0.0.1:6379> info server

info server会吐出一大段服务器信息，里面有redis_version、uptime_in_seconds、config_file这几个字段。特别看一眼config_file，它显示的是当前实际加载的配置文件路径——如果这里是空的，说明你启动时没带上配置文件名，那后面所有配置改动都不会生效，这是新手最常见的一个“改了配置没用”的原因。

3.2 把 Redis 注册成开机自启的 Windows 服务

前台窗口一关 Redis 就停了，这显然不能作为日常方案。Windows 下用自带的命令注册服务，比写批处理脚本靠谱得多。

先以管理员身份打开命令提示符，一定要管理员，否则注册会失败但报错信息很不明显。然后切到 Redis 目录执行：

redis-server.exe --service-install redis.windows-service.conf --loglevel verbose

这条命令里三个部分都有含义。--service-install是告诉可执行文件这次不是启动服务器，而是把自身注册成系统服务；后面的配置文件是服务启动时读取的配置；--loglevel verbose是把服务安装过程中的日志级别调高一点，出问题时你能在事件查看器里看到更多线索。

执行成功不会有太花哨的提示，一般就几行安装信息。然后用这条命令启动：

redis-server.exe --service-start

启动之后回到任务管理器，切到“服务”标签页，应该能看到一个叫Redis的服务，状态是“正在运行”。同时在“详细信息”里会出现一个redis-server.exe进程。这时候你再关掉所有命令行窗口，用redis-cli.exe连一下，照样能PONG，就说明服务注册成功了。

还有一种更省事的做法是用.msi安装包，装完自动注册服务还会顺手加防火墙规则。我不太推荐的原因有两个：一是 msi 对应的版本更老，二是它装完的目录和配置路径都是固定的，你想改数据目录得去翻注册表，不如下载 zip 自己控制。

3.3 服务的启停、卸载和多实例共存

日常用得到的服务管理命令就四条，记住就行：

redis-server.exe --service-start redis-server.exe --service-stop redis-server.exe --service-uninstall redis-server.exe --service-install redis.windows-service.conf --service-name redis6380

最后一条是多实例场景的写法。同一个可执行文件可以注册多个服务，关键是用--service-name给每个服务起不同的名字，再配合不同的配置文件和端口。比如你想在本机同时跑一个 6379 做主库、跑一个 6380 模拟从库，就把两份配置文件分别改好端口和数据目录，然后注册两个服务名。注意数据目录一定要分开，否则两个实例会互相覆盖dump.rdb，数据看着莫名其妙地丢。

卸载服务之前建议先--service-stop，虽然直接卸载也会终止进程，但直接杀进程可能让最后一次持久化没落盘，丢的正好是你刚写的测试数据。

4. redis.windows.conf 里真正需要动手改的几处

4.1 bind 和 protected-mode：本地访问与局域网访问的边界

打开配置文件，bind这一行默认是bind 127.0.0.1，意思是只监听本机回环地址。配合protected-mode yes，这套默认组合是安全的——外面的机器连不上你，你也连不上别人的。

如果你只是本地开发用，别动这两行。我在实际项目里见过太多次“为了图方便把 bind 注释掉、密码也不设”，结果这台机器接在公司网络里，第二天就被人扫到开始写入垃圾数据。真要开放给局域网其他机器访问，正确的做法是三步一起做：把bind改成你本机的局域网 IP（不是0.0.0.0，写具体 IP 更可控）、设置requirepass、在防火墙里只放行需要访问的那几台机器的地址。三件事少一件都不行。

4.2 requirepass：密码怎么设才不让自己难受

requirepass这一行默认是被注释掉的，去掉注释写上密码即可：

requirepass YourStrongPassword_2024

密码本身没什么好说的，我要提醒的是使用侧的两个细节。第一，命令行里直接带密码会被警告，而且密码会进命令历史：

redis-cli.exe -h 127.0.0.1 -p 6379 -a YourStrongPassword_2024

更干净的做法是先连上去，再在交互界面里执行auth YourStrongPassword_2024，或者给当前命令行会话设置环境变量。第二，设了密码之后，你项目里的连接串必须同步改，否则应用侧会一直报NOAUTH Authentication required。这个报错很直白，照着改就行，但如果你用了连接池，可能表现为“间隔性地报认证失败”，那是因为池里还缓存着没带密码的老连接，重启应用即可。

另外提一句，5.0 这套还没有 6.0 那种基于用户的 ACL 体系，只有一把全局密码。要按不同应用分配不同权限，只能靠 5.0 的rename-command把危险命令改名或者禁用，比如把FLUSHALL改成一个没人猜得到的名字，防止误操作。

4.3 持久化：RDB 和 AOF 在 Windows 上怎么取舍

默认配置里只有 RDB，也就是那几行save：

save 900 1 save 300 10 save 60 10000

意思是 900 秒内至少 1 个 key 变化、300 秒内至少 10 个变化、60 秒内至少 10000 个变化时触发一次快照。这是官方默认的折中值，本地开发够用。如果你做的是缓存，数据丢了可以回源重建，那就保持默认，RDB 文件体积小、恢复快。

如果你本地在测试订单、队列这类不能丢的数据，建议开 AOF：

appendonly yes appendfsync everysec

everysec表示每秒刷一次盘，兼顾性能和安全。这里有个 Windows 上特有的体感差异要提醒你：Linux 版做后台保存时会fork一个子进程，主进程几乎不受影响；Windows 这个移植版没有真正的fork，后台保存的实现方式不一样，在数据量比较大、内存占用比较高的实例上执行BGSAVE时，你可能会明显感觉到命令卡顿甚至短暂无响应。所以本地测试大 key 场景时，别奇怪为什么保存期间接口变慢了，这是移植版的固有特性。

4.4 dir、logfile、maxmemory 和那个 Windows 特有的 maxheap

dir ./这一行决定数据文件和 AOF 文件写在哪，相对路径是相对于你启动服务时的当前目录。注册服务之后，工作目录变成系统目录，相对路径就会指向一个你根本没注意的地方。我的建议是直接写绝对路径，路径用正斜杠或者反斜杠都行，但别在里面夹空格：

dir D:/redis/5.0.14.1/data

logfile在服务版配置里默认是一个具体文件名。如果你发现服务在跑但日志目录里什么都没有，检查两件事：这个文件名是不是写了绝对路径、data目录有没有被创建。Redis 不会替你创建不存在的目录，目录不存在时它可能启动失败，也可能静默不写日志，取决于版本。

maxmemory建议一定要设：

maxmemory 512mb maxmemory-policy allkeys-lru

本地机器内存有限，不限制的话一个跑偏的程序能把 Redis 撑到把系统拖卡。配置里还有一个 Windows 特有的maxheap项，用来限制 Redis 进程可申请的堆内存上限。当maxmemory设成 0（也就是不限制）时，至少要给maxheap一个明确值，比如maxheap 1gb，避免进程把物理内存吃干净之后系统开始疯狂换页，整台机器都动不了。

5. 命令行客户端、可视化工具与连不上的排查顺序

5.1 redis-cli 的常用姿势和那个中文乱码

命令行客户端就一个redis-cli.exe，日常最常用的参数是-h（主机）、-p（端口）、-n（选择数据库）、--raw（原样输出，不带引号转义）。带--raw输出中文时经常看到乱码，这不是 Redis 的问题，是 Windows 命令行默认用 GBK 码页，而 Redis 里存的是 UTF-8 字节。解决办法有两个：一是执行chcp 65001切到 UTF-8 码页再连，二是干脆改用可视化工具看。

还有个小技巧，:6379>提示符下按上下箭头能翻命令历史，但 Windows 版的redis-cli历史记录不会持久化，重开窗口就没了。想保留可以把常用命令写成.txt，用redis-cli < commands.txt批量执行，做数据初始化很方便。

5.2 Another Redis Desktop Manager 和 RedisInsight 怎么选

命令行看数据不直观，可视化工具是刚需。市面上常见的有三款，我列个对比：

我日常用 Another Redis Desktop Manager，最主要的原因是它连接信息可以分组管理，本地、测试环境、容器里的实例放在不同分组下，一眼能找到。RSD 那个老版本的 RDM 就不建议再用了，我遇到过它把二进制 key 显示成乱码后再一保存，直接把 value 写坏的情况，虽然是小概率，但数据被工具改坏这件事本身就很难接受。

连接参数填写上，主机127.0.0.1、端口6379、密码填你requirepass设的那个。如果连不上，工具一般会给个弹窗报错，别急着到处改配置，先按下面的顺序查。

5.3 连不上的时候按这个顺序查，别乱试

这张表里的排查顺序是有讲究的：从“进程在不在”到“网络通不通”再到“认证过不过”，逐层缩小范围。很多人一看到连不上就去改配置文件，改完重启服务，还是连不上，最后发现是服务根本没启动。先确认最底层的事实，比反复试配置高效得多。

6. 我在 Windows 上装 Redis 踩过的六个真问题

6.1 服务注册成功，启动后几秒钟又停了

这是最高频的问题，排查链路是这样的。第一步，先看是不是配置文件路径错了——服务注册时如果写的是相对路径，工作目录一换就找不到文件，启动会立刻退出。把--service-install那条命令里的配置文件改成绝对路径重新注册一次。第二步，看日志文件。服务版的日志会写在配置里logfile指定的位置，打开看最后几行，通常会明确写是端口占用还是目录权限。第三步，如果日志文件压根没生成，那就是dir目录不存在或者权限不够，手动建好目录再试。

我遇到过一次特别隐蔽的情况：日志里只写了一句“Failed to save the DB”，查了半天发现是dir指向了一个被同步盘监控的目录，同步进程锁着这个文件夹，Redis 写不进去。把数据目录挪出同步范围就好了。所以数据目录别放在网盘同步目录、别放在杀毒软件实时监控的目录，这是个很少被提到但确实会出问题的点。

6.2 局域网里同事连不上我的 Redis

按前面说的，先确认服务本身没问题（本机redis-cli能连），再确认监听地址。如果bind还是127.0.0.1，那无论防火墙怎么开，外部都连不上。改bind之后，接着看防火墙。用管理员命令行加一条入站规则：

netsh advfirewall firewall add rule name="Redis 6379" dir=in action=allow protocol=TCP localport=6379

加完之后如果还不行，检查是不是还有一条更高优先级的阻断规则，或者网络配置文件被识别成了“公用网络”，而你的规则只对“专用网络”生效。这个坑在 Windows 10 上很常见，公司网络一动，网络位置就从“专用”变成“公用”，规则失效。建议规则里把 profile 设成 any。

删规则的话用：

netsh advfirewall firewall delete rule name="Redis 6379"

6.3 日志不生成，改完配置不生效

这两个问题往往是同一件事的两个表现。redis.windows.conf和redis.windows-service.conf是两份不同的文件，前台启动和服务启动读的不是同一份。你改了redis.windows.conf但服务读的是redis.windows-service.conf，配置当然不生效。判断方法也很简单，连上之后执行config get dir、config get logfile，看返回值跟你改的是不是一致。

另一个原因是服务注册之后，配置文件的路径被写进了注册表。你后来把配置文件挪了位置或者改了名字，服务还在按老路径找，找不到就用默认配置启动。这时候要么把文件挪回去，要么卸载服务重新注册。我现在的做法是配置文件固定不动，只改内容，省得记这些路径关系。

6.4 电脑重启之后数据没了

默认配置下没开 AOF，RDB 又有触发条件，如果你写完数据马上就关机或者直接杀进程，最后一次快照根本没执行，数据自然丢。两个改进方向：要么把appendonly打开，要么在关机前手动执行一次save（注意save是阻塞的，数据量大时会卡住主线程，用bgsave更好）。

还有一种更隐蔽的丢数据方式：你以为数据在，其实服务连的是另一个目录。多实例场景下两个实例共用同一个dir，A 实例的dump.rdb被 B 实例覆盖了。判断方法是执行config get dbfilename和config get dir，把每个实例的这两项确认一遍，确保互不重叠。

6.5 内存占用看着不对劲

本地跑 Redis 容易忽略内存这件事。执行info memory能看到used_memory_human和used_memory_rss两个值，正常情况下它们差距不会太大；如果 RSS 明显高于 used_memory，说明内存碎片较多，或者有大量已删除但未释放的空间。可以试一下memory doctor（5.0 支持）看看它的建议。

还有一个 Windows 上特有的现象：你设了maxmemory 512mb，但任务管理器里看到的进程占用远超这个数。这跟 Redis 自身的内存统计口径以及 Windows 内存分配机制有关，maxmemory限制的是数据集大小，不是进程的全部开销。所以别把maxmemory设到接近物理内存上限，留至少三分之一给系统和其他程序，否则系统开始换页，Redis 会慢得让你怀疑配置写错了。

6.6 卸载服务之后重装失败

--service-uninstall执行之后，如果服务列表里还能看到同名服务残留，重新注册会失败。这时候去服务管理器（services.msc）看一眼，如果状态是“已停止”但还在，手动删掉，或者用sc delete 服务名强制删除。另外，数据目录和日志目录不会随服务卸载一起清理，重装之后如果连上了发现还是旧数据，别慌，那是你自己的数据文件还在。

7. 环境跑通之后，拿它做点什么

7.1 用五种基础数据类型把环境验证一遍

装完就放着吃灰太浪费，花十分钟把核心数据类型跑一遍，一是验证环境，二是顺便熟悉命令。Redis 的五种基础类型：字符串、哈希、列表、集合、有序集合，日常开发里九成场景都在这五个里面。

127.0.0.1:6379> set user:1:name "张三" 127.0.0.1:6379> hset user:1 age 28 city "杭州" 127.0.0.1:6379> rpush queue:tasks "task-a" "task-b" "task-c" 127.0.0.1:6379> sadd tags:article:1 "redis" "windows" "cache" 127.0.0.1:6379> zadd rank:score 95 "player-a" 87 "player-b" 92 "player-c" 127.0.0.1:6379> zrevrange rank:score 0 -1 withscores

哈希适合存对象的字段，比把整个对象序列化成字符串再取出来改要省事；列表天然适合做队列，lpush加rpop就是一个简单的任务队列；有序集合适合排行榜、延时队列这类需要按分值排序的场景。这几条命令跑完，你对每种类型的读写方式就有了体感，比看文档记得牢。

7.2 用 redis-benchmark 压一下，感受本机性能

redis-benchmark.exe就在解压目录里，用它可以快速看看本机 Redis 的大致吞吐：

redis-benchmark.exe -h 127.0.0.1 -p 6379 -n 100000 -c 50 -q

-n是总请求数，-c是并发连接数，-q只输出关键结果。它会列出SET、GET、INCR等命令每秒能处理多少请求。Windows 上的数字通常比同配置的 Linux 低一截，这很正常，移植版在 IO 模型上确实有天然劣势，别拿这个数字去对比生产环境的基线。这个工具真正的价值在于：你改动配置（比如调大maxmemory、开关 AOF）之后跑一次，能直观看到改动对性能的影响。我自己试过开 AOF 的everysec模式，写入性能的下降幅度比预想中小，这也是为什么我建议对数据可靠性有要求时直接开它。

7.3 从本地单机往后延伸的几条路

本地单机跑通之后，往下走通常有三个方向。第一个是实验主从复制，最简单的办法是用 Docker 起两个容器，一个配replicaof指向另一个，观察主库写入从库同步的过程；如果你不想引入容器，也可以在本机注册两个服务实例，分别用 6379 和 6380 端口，配置文件里写明replicaof 127.0.0.1 6379，效果一样。第二个是分布式锁，本地环境正好用来复现锁超时、误删别人锁这些经典问题，用set key value nx px 10000加一个唯一标识值，再写段代码故意让业务执行超过 10 秒，你就能亲眼看到锁失效后的并发问题，这种实验比看面试题答案印象深得多。第三个是缓存治理，本机接一个真实项目，把info stats里的命中率、慢查询日志打开，观察一段时间，你会对“哪些 key 该设过期时间”“缓存穿透长什么样”有直观感受。

这三个方向都需要一个稳定的本地 Redis 作为基础，而你现在已经有了。把服务设成开机自启、配置文件和数据目录固定下来、日志能正常写，剩下的就是慢慢折腾了。我在自己机器上的习惯是数据目录单独放、每个月清一次，避免测试数据越积越多把磁盘占满——这个习惯帮我省过好几次空间告急的麻烦。