ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Windows上安装Redis全攻略:方案选型、配置指南与踩坑实战

Windows上安装Redis全攻略:方案选型、配置指南与踩坑实战 之前也写过好多回“在 Windows 上装 Redis”每次都觉得是个五分钟能搞定的小事结果一深入就发现坑全藏在后头。项目标题写着“windows安装redis”热搜词里还带着redis下载、redis安装配置、redis desktop manager这些关键词可见大家碰到的都是同一类问题版本选哪个、怎么启动、怎么设密码、要不要注册成服务、数据怎么持久化、用啥客户端连。这篇就把我在 Windows 上装 Redis 踩过的坑、验证过的路径、真正实用的配置一次性捋清楚。先说结论Windows 上跑 Redis 不是不能搞官方确实没有正式支持 Windows但社区维护的版本和容器化方案都足够成熟开发调试、本地验证完全够用。关键是别把 Linux 那套思路死搬到 Windows也别把生产环境的 Redis 拿来跟 Windows 版硬比搞清楚目标再动手整个过程会顺很多。下面按我的习惯从方案选型开始讲一步步走到能启动、能连接、能持久化、能排查问题。1. Windows 上装 Redis先把方案选明白1.1 为什么官方一直不给 Windows 版不少人第一次听说 Redis 官方不支持 Windows 的时候都会愣一下。Redis 官方从 2012 年左右开始就明确提出不对 Windows 提供原生支持Windows 版主要由社区维护。原因倒不复杂Redis 天生依赖 fork()、epoll、写时复制这些 POSIX 语义Windows 的内核模型跟 Linux 差异太大硬移植要么改太多核心代码要么性能和稳定性跑偏。真要怪不如怪 Windows 当年对异步网络和进程模型的支持跟 Unix 系长得太不一样。但这对咱们普通开发者影响没那么大。本地开发跑一个 Redis 存缓存、存会话、测队列根本用不到极端场景社区维护的 Windows 二进制已经非常稳定。选对版本、熟悉差异Windows 开发环境完全够用。1.2 主流安装方式横向对比我自己试过四条路线各有适用场景方案优点缺点适合谁ZIP 解压版快速、可控、可注册服务一条命令启动需要手动处理配置和自启动本地开发、学习需要完全控制 Redis 行为MSI 安装包装完自带服务Windows 服务里直接管理版本偏旧部分旧包不支持最新特性懒得折腾、只要能跑的人Docker Desktop干净、隔离跟生产环境最接近可模拟集群需要装 Docker Desktop占资源较多要模拟 Linux 环境、跑主从/哨兵、之后要上云的人WSL2原生 Linux 二进制统一环境需要启用虚拟机平台网络和文件互通有点绕习惯用 Linux 命令、想在 Windows 上跑一个“真 Linux” Redis这四条的选型逻辑不一样。ZIP 解压版是我个人最常用的因为开发机上我不想要一堆服务常驻想用的时候双击一个脚本启动不用的时候直接关掉。MSI 适合给不写代码的同事部署装完自动在服务里跑起来省心。Docker 和 WSL2 适合那些明确知道我最终要部署到 Linux 服务器的人早点统一到 Linux 环境能少踩很多坑。1.3 三种场景的最优解建议如果只是看这篇博客想快速体验我建议直接用 ZIP 解压版原因在后面会详细展开。如果是给团队搭个公共开发 Redis并且大多数人只在 Windows 上开发可以选 MSI 或 Docker 方案。如果明确要往生产环境部署我更推荐直接装 Docker Desktop然后跑一个官方 Redis 镜像这样从开发到部署的命令基本不用换。这个“场景先行”的思路很重要。我见过特别多人在第一步就纠结哪个版本最新其实版本不是关键方案是不是适合你的目标才是关键。选错方案后面改起来比装的过程还烦。2. ZIP 解压方案最直接的手工安装法2.1 下载与目录准备ZIP 解压版的核心是拿到一份编译好的二进制文件。搜索“redis windows 下载”能搜到很多来源但这里要特别提醒一句优先选社区维护的镜像常见的是 tporadowski 维护的版本以及部分国内镜像站转存的二进制包版本一般是 5.x 或 7.x选版本的时候留意一下发布时间和是不是官方的 release 转存。不建议去来路不明的网站下别人打包好的所谓“绿色版”很容易夹带东西。我习惯的目录结构是这样的D:\redis\ redis-server.exe redis-cli.exe redis.windows.conf redis.windows-service.conf解压后第一步不是急着双击 redis-server.exe而是先把目录权限和防火墙规则理清楚。如果目录放在系统盘或者用户目录下后续注册服务可能出现权限问题最省心的做法是放到一个单独的盘符根目录下比如 D:\redis避免 UAC 权限拦截。2.2 修改配置文件这一步千万别跳ZIP 包里的 redis.windows.conf 就是主配置。用任意文本编辑器打开重点确认几个参数# 用 Redis 默认端口 port 6379 # 如果只是本机用保持默认 bind 127.0.0.1 # 如果想让局域网其他机器访问改成 0.0.0.0 # bind 0.0.0.0 # 保护模式默认开启本机访问不受影响 protected-mode yes # 设置密码强烈建议设置 # requirepass yourpassword # 持久化策略默认 RDB # save 900 1 # save 300 10 # save 60 10000重点说几个理解起来容易偏的地方。bind 参数控制 Redis 监听哪个网卡默认 127.0.0.1 意味着只有本机能连这对安全性来说非常友好。如果开发机上装了 WSL 或者虚拟机又希望从虚拟机里连到 Windows 上的 Redis就需要把 bind 改成 0.0.0.0这时候 protected-mode 就尤其重要它会在没有设置密码的情况下拒绝非回环地址的连接所以要么设置 requirepass要么不要随便开 0.0.0.0 监听。requirepass 这一项很多人会忽略但一旦 Redis 监听了公网网卡又没有密码极容易被扫描器接管。我在之前的项目里遇到过未授权访问的事情恢复成本远高于当时五分钟的密码设置时间。所以我的建议很直接只要 bind 不是 127.0.0.1就一定要设置一个复杂的 requirepass。持久化策略我放在后面专门讲这里先确认 RDB 默认开着就行。配置文件里那些以 # 开头的默认值建议先保留原样跑通了再按需调整避免一上来就配错导致 Redis 起不来。2.3 前台启动测试先别急着注册服务改完配置在当前目录打开命令行先跑前台模式redis-server.exe redis.windows.conf正常启动会显示一个 ASCII 文字 logo然后打印端口、模式、持久化等信息。看到 “Ready to accept connections” 就说明起来了。这个步骤为什么不能省因为如果配置有问题前台启动会直接把错误打在终端里比注册成服务后再慢慢抠日志要直观得多。启动成功后开一个新终端用自带的命令行客户端验证redis-cli.exe -p 6379 127.0.0.1:6379 ping PONG 127.0.0.1:6379 set name hello redis OK 127.0.0.1:6379 get name hello redis 127.0.0.1:6379 exit如果设置了 requirepass连接后要先执行auth yourpassword或者启动时用-a参数不然所有命令都会提示NOAUTH Authentication required。这一步验证完代表核心二进制和配置没问题接下来才做服务注册。2.4 注册为 Windows 服务实现开机自启前台模式适合调试但真正日常使用还是注册成 Windows 服务方便。Redis 自带的--service-install参数就是干这个的。我的标准做法是停止前台运行的实例然后在管理员权限的命令行里执行redis-server.exe --service-install redis.windows.conf --service-name Redis redis-server.exe --service-start --service-name Redis第一条把 Redis 注册成名为 Redis 的 Windows 服务第二条把它启动起来。以后开机是自动运行的如果中途改配置用--service-restart重启即可。卸载服务命令是redis-server --service-uninstall --service-name Redis本地开发机如果不想常驻随时卸载就好。这里有一个服务配置文件的小细节要注意注册服务用的是 redis.windows-service.conf 还是 redis.windows.conf取决于你的命令怎么写。我建议单独建一个 redis.windows-service.conf内容基于 redis.windows.conf 再额外把日志输出到文件方便排查服务方式启动的问题。# redis.windows-service.conf # 基于 redis.windows.conf 追加如下配置 daemonize no logfile D:/redis/logs/redis.log日志文件路径尽量不要放在 C 盘系统目录下避免权限不够写不进去。服务启动失败的时候查看这个日志文件基本能定位 80% 的问题。2.5 过程验证检查端口和服务状态注册完成后用几个命令快速验证sc query Redis netstat -ano | findstr 6379 redis-cli.exe -p 6379 pingsc query Redis能看到服务的运行状态是 RUNNING 还是 STOPPED。netstat能看到 6379 端口是否在监听。redis-cli ping验证业务层面是否正常。这三条都通过ZIP 方案就算完全落地。3. 用 Docker 跑 Redis容器化是更省心的选择3.1 为什么我推荐走一遍容器方案如果说 ZIP 方案解决的是“最快跑起来”的问题那么 Docker 方案解决的是“最接近生产”的问题。后面的开发环节无论项目里用 Spring Boot、Node.js 还是 Python最终部署大概率都是 Linux 服务器而服务器上的 Redis 基本也都是用 Docker 或者 K8s 跑的。本地直接用 Docker命令和参数几乎完全一致不会出现在 Windows 上测得好好的、一到 Linux 就不对劲的情况。代价是 Windows 上需要先装 Docker Desktop。装 Docker Desktop 的过程本身不算复杂但有个关键点它依赖 Hyper-V 或 WSL2 后端。新版的 Docker Desktop 默认用 WSL2所以大概率需要开启系统虚拟机平台和 WSL 功能。这一步如果没开好Docker Desktop 会一直卡在启动阶段这跟搜“codex windows安装未完成”“docker windows”时看到的类似问题都属于基础环境不满足。3.2 启动一个标准 Redis 容器Docker Desktop 跑起来之后开一个终端直接拉镜像docker pull redis:7.0然后跑容器docker run -d \ --name redis-local \ -p 6379:6379 \ -v D:/redis-data:/data \ redis:7.0 \ redis-server --appendonly yes简单解释一下这几行参数。-d表示后台运行--name是容器名-p 6379:6379把宿主机的 6379 映射到容器内的 6379。-v D:/redis-data:/data是把 Windows 的目录挂载到容器里的数据目录这样 Redis 的持久化文件会写到 Windows 磁盘上容器删了数据也还在。最后面的redis-server --appendonly yes是容器的启动命令等效于把配置文件里的 AOF 开关打开。启动完检查一下docker ps docker exec -it redis-local redis-cli ping能看到容器状态和 PONG 返回说明 Redis 在容器里跑得很健康。用 Docker 的好处这时候就体现出来了不用关心二进制放哪、不用注册服务一个命令就能启动再一个命令就能删干净。3.3 挂载自定义配置文件的方式如果项目里对 Redis 配置有明确要求更好的做法是把配置文件放到挂载目录中然后用--config-file加载。比如在 D:/redis-data/redis.conf 里写port 6379 appendonly yes appendfsync everysec maxmemory 512mb maxmemory-policy allkeys-lru启动命令改成docker run -d \ --name redis-conf \ -p 6379:6379 \ -v D:/redis-data:/data \ -v D:/redis-data/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7.0 \ redis-server /usr/local/etc/redis/redis.conf这里有一个非常容易踩的坑容器内 Redis 的用户和文件权限默认可能和数据目录权限不一致挂载目录如果权限不对第一次启动会报Cant open the append-only file: Permission denied。Windows 挂载到 WSL2 时通常问题不大但如果你用普通目录而不是 Docker Desktop 默认的共享目录还是建议先docker run进去看一眼目录写权限或者在 Windows 目录权限里给 Users 增加写权限。3.4 用 Docker 顺手演练主从复制既然都上了 Docker一个附加价值就是能本地模拟主从结构这条对准备面试或者准备上生产的人来说特别划算。Docker 网络里开两个容器做一主一从docker network create redis-net docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7.0 docker run -d --name redis-slave --network redis-net -p 6380:6379 redis:7.0 \ redis-server --replicaof redis-master 6379从节点的--replicaof参数指定了主节点地址。验证同步状态docker exec -it redis-slave redis-cli info replication输出里role:slave和master_link_status:up就说明主从已经连上了。在主节点写一个 key再到从节点读能读到就代表真正的复制流程在本地工作正常。这一步以前我在纯 Windows 环境想模拟还挺麻烦现在用 Docker 两分钟搞定强烈建议装完顺手试一下。4. 安装完别急着用这些配置和工具有必要安排4.1 redis.conf 里必改的几个关键参数很多人在 Windows 上装完 Redis什么都不改就开始用这能用但不安全也不规范。我把日常项目里一定会调整的配置列出来按优先级排序第一优先级安全与访问控制bind 127.0.0.1 # 只允许本机访问 protected-mode yes # 保护模式 requirepass 请改成强密码 # 设置访问密码 rename-command KEYS # 危险命令禁用或者改名第二优先级性能与内存上限maxmemory 512mb maxmemory-policy allkeys-lru设置 maxmemory 非常关键。不设上限的话缓存数据无限增长最终把内存耗尽Windows 系统会变得非常卡任务管理器一开发现 Redis 占用了十几个 GB这种情况我见过不止一次。配合 maxmemory-policy 设置淘汰策略比如allkeys-lru会在内存满了之后自动淘汰最久没使用的 key这对缓存场景是合理的。第三优先级持久化配置save 900 1 save 300 10 save 60 10000 appendonly yes appendfsync everysecRDB 和 AOF 可以同时开。开发环境下 AOF 建议开因为 AOF 比 RDB 的丢失数据窗口小得多每秒钟刷一次盘最多丢一秒数据。数据丢了调试半天比多花一点磁盘空间更难受。4.2 可视化客户端横向对比命令行操作适合验证和排查但平时真要给 key 分类、看 TTL、看内存使用我还是建议装个可视化工具。热词里搜“redis desktop manager”和“another redis desktop manager”的人很多实际情况也是这两款为主。Redis Desktop ManagerRDM是老牌客户端功能全但新版已经转向商业授权官方版本免费额度有限。Another Redis Desktop Manager简称 ARDM是国内开发者维护的开源项目界面简洁支持 Windows/Mac/Linux连接、增删改查、查看内存、订阅频道这些常规操作都很顺手作为日常调试工具够用了。连接的时候填三个信息host本机就填 127.0.0.1、port默认 6379、password如果设置过 requirepass。如果连接不上先从命令行验证redis-cli -a 密码 ping命令行能通就说明是客户端配置问题命令行不通则是 Redis 服务本身的问题这个排查思路能省好多时间。4.3 认识一下 Redis 的常见数据类型装好 Redis 之后顺手把常见数据类型过一遍很有必要热词里“redis数据类型”和“redis面试题”高频出现说明这是大家普遍的关注点。Redis 最核心的类型是 String、List、Hash、Set、ZSet另外还有 Bitmap、HyperLogLog、Stream 这些高级结构。开发中最常用的是 String 和 Hash# String最基础的 key-value set cache:user:1 {\name\:\test\} ex 3600 get cache:user:1 # Hash适合存对象 hset user:1 name test age 18 hgetall user:1 # List适合做简单的消息队列 lpush task:queue task1 rpop task:queue # Set适合做去重、交集计算 sadd tags:news tech redis sinter tags:news tags:hot # ZSet适合排行榜 zadd ranking 100 player1 zincrby ranking 10 player1 zrevrange ranking 0 -1 withscores记住一个规律Redis 里的命令大多是一个动词加一个 key对应不同数据结构的操作只是动词不同。熟悉了这几个命令就能应对绝大多数场景。4.4 命令行验证三板斧不管有没有可视化工具有一些排查命令必须手熟redis-cli.exe -a 密码 -p 6379 # 查看当前所有 key生产环境慎用 KEYS量大卡死 keys * # 查看当前数据库 key 数量 dbsize # 查看 Redis 运行状态 info # 查看内存使用 info memory # 查看连接 client list # 查看慢查询 slowlog get 10KEYS *在开发机没问题但在生产环境数据量大的情况下会导致 Redis 阻塞这一点面试官爱问实际运维也要注意。排查问题的顺序建议是先 ping 看通不通再 info 看整体状态再 dbsize 看数据量最后 slowlog 看有没有慢命令。5. 踩坑记录这些坑我替你踩过了5.1 服务启动失败 / 双击闪退这是 Windows 上 Hello World 级别的坑。双击 redis-server.exe 一个小黑窗闪一下就没了原因无非三类配置文件格式错误比如把版本的参数写错或者粘贴了 Linux 下#注释没注意。解决办法是用命令行前台启动错误信息会直接显示在终端里从报错内容去改配置比瞎猜快得多。端口被占用。如果 6379 被别的进程占用了Redis 会启动失败。先用netstat -ano | findstr 6379查出占用进程任务管理器里确认是不是自己之前启动的 Redis 没关干净或者就是别的服务占用了。本地开发机如果每次开机都有一堆程序抢端口建议把 Redis 的端口改成一个相对少用的端口比如 6380。目录或者日志文件没有写权限。注册 Windows 服务时服务运行在系统账户下配置文件里如果指定了日志路径这个路径必须让系统账户能写否则服务起来又立刻崩溃。我常用的排查套路是三步走前台启动看报错检查端口占用再看日志文件。90% 的问题在三步内能解决。5.2 局域网连不上 Redis如果 Windows 上 Redis 已经跑起来了但局域网里其他机器连不上先别急着怀疑 Windows 防火墙。实际最大的可能是 bind 配置导致 Redis 只监听了 127.0.0.1。用netstat -ano | findstr 6379查看监听地址TCP 127.0.0.1:6379 0.0.0.0:0 LISTENING如果看到地址是 127.0.0.1说明 Redis 根本没监听外部网卡无论防火墙怎么放行都没用。需要在配置文件里把 bind 改成bind 0.0.0.0然后重启服务。改完后 netstat 应该显示TCP 0.0.0.0:6379 0.0.0.0:0 LISTENING如果是 Docker 跑的还要确认-p 6379:6379端口映射有没有写对。集群里从节点或者客户端连不上八成是端口映射和 bind 两层问题叠加。5.3 数据一重启就没了这个也是高频问题。Redis 默认的 RDB 持久化会在特定触发条件下保存快照比如 900 秒内至少有 1 个 key 改变才保存。如果写入数据后立刻重启又没触发快照条件数据就会丢失。解决办法很简单配置文件里显式加上save 900 1 save 300 10 save 60 10000 appendonly yes appendfsync everysecAOF 开启后每次写操作都会追加到文件里。拿 Windows 任务管理器关掉 Redis 服务再重启数据还能恢复。这里有个小细节Windows 下如果直接强制杀进程或者关机AOF 文件可能留下未完成的追加记录Redis 重启会自动做aof-load-truncated处理把它当日志开头正常 load。超出的部分一般不影响数据完整性不用担心。5.4 Docker 容器里的 Redis 无法持久化Docker 方案里最容易被忽略的是容器删除时数据一起消失。如果启动命令里没有用-v挂载/data目录Redis 的数据就写在容器可写层里docker rm之后再跑新容器所有数据都没了。排查的关键是看启动命令里有没有挂载docker inspect redis-local --format {{.Mounts}}如果 Mounts 为空说明数据确实没持久化。正确做法是启动时加-v D:/redis-data:/data而且要注意 Windows 下挂载目录不要放在系统临时目录防止清理软件把整个目录删掉。我之前就经历过系统自带的磁盘清理把临时目录里的 Docker 数据清掉的惨剧从此一律放到专门的 D 盘目录。5.5 常见问题速查表把上面提到的和日常维护中几个高频问题整理成一张表直接对照解决现象可能原因排查/解决redis-server.exe 双击闪退配置文件错误用命令行前台启动看报错信息服务启动后马上停止日志目录无写权限给日志路径授权或换到 D 盘redis-cli ping 提示 NOAUTH设置了密码但没认证执行 auth 密码或连接时加 -a局域网连不上bind 127.0.0.1改成 bind 0.0.0.0重启服务连接被拒绝端口被占用netstat 查询端口清理或改端口数据重启丢失没开持久化开启 AOF或确认触发条件Docker 容器删了数据没了没挂载 /datadocker run 加 -v 挂载内存占用越来越大没设置 maxmemory配置 maxmemory 和淘汰策略6. 装完 Redis 之后顺手验证的几个高频场景6.1 缓存场景的读写验证装了 Redis 之后最直接的玩法就是当缓存。比如你有个接口计算结果很慢可以把结果放到 Redis 里设置过期时间# 模拟缓存写 set user:profile:123 {...} ex 300 # 缓存读 get user:profile:123 # 检查剩余过期时间 ttl user:profile:123TTL 返回 -1 表示没有过期时间-2 表示 key 不存在。这个命令在排查缓存是否被误删、是否设置过期时间时非常有用。项目里经常会问为什么不直接用内存缓存非要引入 Redis答案其实就是三点进程间共享、集中管理过期、多个服务实例共用同一份缓存。6.2 分布式锁的基本用法热词里有“redis分布式锁”和“redis面试题”这也是装完 Redis 一定要会的基础操作。Redis 分布式锁用一条命令就搞定SET lock:order:123 token-abc NX PX 30000NX 表示只有 key 不存在时才设置成功PX 30000 表示 30 秒后自动过期。设置成功就说明拿到了锁业务处理完再执行 Lua 脚本删除锁保证原子性。重点要理解为什么要带过期时间因为如果拿锁的进程崩溃了没有过期时间锁就永远解不开形成死锁。这套东西自己手动实现容易踩坑项目里通常直接用 Redisson 这类客户端提供的现成锁但底层原理就是上面这条命令。6.3 网上聊得火热的缓存治理三兄弟一旦项目上了 Redis缓存穿透、缓存击穿、缓存雪崩就是绕不开的话题。穿透指请求的数据压根不存在每次都会打到数据库击穿指某个热点 key 失效的瞬间大量请求直接打到数据库雪崩指大量 key 同时过期数据库压力飙升。应对思路也简单穿透用布隆过滤器或者缓存空值击穿用互斥锁重建缓存雪崩给过期时间加随机因子尽量分散在同一时间点过期的风险。这些知识点配合你刚装好的 Redis 一个个实验着玩比光看面试题记得牢得多。7. 从 Windows 到 Linux迁移前最后说两句最后分享一点个人体会。Windows 上装 Redis 只是起点我自己的经验是无论是在 Windows 上用 ZIP 还是 Docker 把 Redis 跑顺之后都要给自己留一个“迁移到 Linux”的预案。社区版 Windows 版 Redis 通常停留在 5.x 或 7.x而 Linux 官方版迭代速度很快新特性如 Redis Stack、JSON 模块、向量检索这些在 Windows 上体验差距明显。如果项目真的在 Windows 上遇到了性能或功能瓶颈下一步多半就是把 Redis 迁到一台 Linux 服务器上然后用同样的逻辑跑起来。配置文件大同小异只是从 redis.windows.conf 变成 redis.conf把 bind、requirepass、持久化这些参数再检查一遍就行。还有一个很实用的建议在 Windows 上开发时尽量把 Redis 的相关命令写成一个 bat 或 PowerShell 脚本比如 start-redis.bat、stop-redis.bat 和 flush-redis.bat。这样团队里其他同事拿到项目后不需要背诵 redis-server 那一长串命令一键起服务、一键清缓存开发体验会提升很多。我自己的脚本目录长这样echo off echo Starting Redis... cd /d D:\redis redis-server.exe redis.windows.confecho off echo Stopping Redis... net stop Redis echo Done.脚本虽小但对团队协作的帮助很大。我在实际带项目的时候发现很多同事并不是不会装 Redis而是每次都要现搜命令、现查参数脚本化之后就再没出过问题。这也是这篇文章最后想强调的一个点安装只是第一步把整个使用流程固定下来、让别人也能一键复现才是真正把工具用到位了。
返回列表