1. 为什么要在Windows上折腾Redis环境
先说个实际场景:我经常在本地开发时遇到这种情况——代码里用到了缓存、分布式锁、或者需要模拟队列任务,但公司的测试环境Redis还在别的团队手里维护着,改个配置都要走工单。每次调试都卡在环境依赖上,特别耽误事。后来我养成了一个习惯,不管换哪台电脑,第一件事先把本地Redis环境装好。Windows下搭建Redis其实没有很多人想得那么复杂,但也确实有一些坑需要提前避开,这篇就按我自己两次三番踩坑后沉淀下来的流程,把完整的搭建和使用过程捋一遍。
Redis是什么,简单说就是一款基于内存的键值存储系统,官方名字叫Remote Dictionary Server,支持字符串、哈希、列表、集合、有序集合这些数据结构,还能做缓存、消息队列、分布式锁、排行榜等等。它最讨喜的特点是快,因为数据全部在内存里操作,单机TPS能到十万级,加上内置了RDB和AOF两种持久化机制,即使机器重启数据也不会全部丢失。这也是为什么它成了目前互联网后端服务里几乎绕不开的基础组件。
那为什么非要在Windows上装它,而不是直接连远程Linux服务器?几个原因很实在:本地开发调试方便,断点调试时随时看数据状态;不依赖测试环境排期,自己搭一套想怎么造数据怎么造;学习Redis数据结构和命令时,本地搞一个实例远比连远程库来得酣畅。这篇文章适合刚接触Redis的前后端开发、测试工程师,还有想系统学习Redis数据类型的同学。照着流程走完,你能在自己的Windows机器上得到一个能正常读写数据、支持持久化、带可视化操作界面的完整Redis服务。
可能有人会说,Redis官方不是不推荐在Windows上跑吗?这话不假,官方文档也明确说生产环境建议跑在Linux上,但那是针对生产环境的建议。本地开发、个人学习、功能自测,Windows下跑Redis完全够用,市面上几乎所有主流语言都有Windows版的Redis客户端,数据库中间件联调也不受影响。别被"生产环境用Linux"这句话吓退,先能在本地把环境跑起来,后续要上生产再迁移到Linux,思路是一样的,只是配置略有差别。
2. 环境搭建前的准备工作
2.1 版本选择思路
这是开工前最重要的一步,也是网上最容易让人迷惑的地方。Redis官网目前不直接提供Windows安装包,官方的Windows支持计划也一直停留在很早期的版本。所以你在网上搜到“Redis官方Windows版下载”,八成是第三方维护的发行版,得看清来源。
目前Windows平台使用最广泛的有两个来源:一个是Microsoft Open Tech团队维护的Redis on Windows,这套是基于Redis 3.2的修改分支,比较适合对版本没有特别要求的场景,但说实话版本太老了;另一个是tporodowski维护的Redis Windows发行版,它把Redis 5.0.x移植到了Windows平台,同时支持安装为Windows服务,是我个人实测下来最省心的一套。近几年Redis更新到7.x之后,官方依然没有正式发布Windows安装包,所以Windows用户现阶段主力方案还是基于5.0.x的这套移植版。
选型建议很直接:如果是本地做基础学习、SpringBoot项目练手、缓存功能测试,用Redis 5.0.x这套就够了,功能语义和Linux版完全一致;如果是为了配合新版本中的某些新命令做验证,那可以考虑用Docker在Windows里跑Linux容器装Redis 7.x,但这已经属于Docker方案了,不在本教程基础范围内。记住一个原则:本地开发宁可版本保守,也别追新追出兼容问题。
2.2 下载渠道与文件核查
去GitHub上找tporodowski/redis这个仓库的Releases页面,下载最新Release里的Redis-x64-x.x.x.zip压缩包。这个仓库的Release包已经做了函数库静态链接处理,直接解压就能运行,不需要再装什么额外的VC运行库,这一点比某些第三方打包站靠谱得多。
下载时留意两点。一是别从来源不明的软件站下载,我之前试过某个下载站提供的“Redis稳定版”,压缩包里被塞了额外的广告程序,解压出来一堆不明exe,吓得我直接删了。二是核对压缩包里的文件结构,正常解压后应该能看到redis-server.exe、redis-cli.exe、redis-benchmark.exe这些核心可执行文件,以及redis.windows.conf、redis.windows-service.conf两个配置文件。如果少了配置文件,后面很多参数配置就得手动加,会麻烦不少。
2.3 系统环境要求
Windows 10、Windows 11、Windows Server 2016及以上的版本都能正常运行,不需要特别高的硬件配置,内存4G以上就绰绰有余,毕竟Redis默认配置对内存占用也就几百MB级别,除非你往里面灌大量数据。需要注意的一点是,如果之前的端口被占用,启动会报错,这个我后面专门讲排查方法。
还有一个小准备:建议把解压目录放到一个路径中没有中文和空格的纯英文目录下,比如D:\Redis。这不是玄学,是因为某些工具链和脚本在解析路径时遇到中文目录会出现编码错乱,Visual Studio生成的项目、Python脚本、Java的application.yml里的配置都会牵扯到路径解析,与其后面莫名其妙报错,不如一开始就把路径搞干净。
3. 完整安装与启动配置流程
3.1 解压与静态文件结构
把下载好的zip包解压到指定目录后,你会看到一个这样的文件列表:redis-server.exe(服务器主程序)、redis-cli.exe(命令行客户端)、redis-benchmark.exe(压力测试工具)、redis-check-aof.exe(AOF文件检查修复工具)、redis-check-dump.exe(RDB文件检查修复工具)、redis.windows.conf(标准配置文件)、redis.windows-service.conf(用于Windows服务运行模式的配置文件)。
先花一分钟把结构理解清楚,后面所有操作都围绕着几个文件和配置展开。redis-server.exe就是我们要启动的核心进程,redis-cli.exe是手动操作Redis的交互工具,那个conf配置文件决定了Redis以什么参数运行。你可能注意到了有两个conf文件,redis.windows.conf是手动启动时默认加载的,redis.windows-service.conf是注册为Windows服务后使用的。两者内容差别不大,但如果你采用服务方式运行,建议修改服务配置文件,否则容易遇到“改了配置没生效”的错觉。
3.2 核心配置参数解析
用记事本或者VS Code打开redis.windows.conf,重点看以下几个参数。
bind参数默认是127.0.0.1,表示只允许本机连接。如果你只是想本地开发用,保持默认就好,不要改成0.0.0.0,那样会暴露在局域网内,没有密码保护的情况下等于裸奔。protected-mode默认是yes,这个和bind是配合使用的安全机制,本地使用保持默认。port默认6379,除非端口冲突,否则不建议改,因为很多框架的默认配置都是连6379,改了之后每个客户端都要跟着改,纯属给自己添麻烦。
requirepass参数默认是被注释掉的,大家可以根据需要设置访问密码。本地纯学习环境可以不设,但如果你打算让局域网内其他同事连你的Redis做联调测试,务必设置一个强密码,避免被扫端口之后被恶意清空数据。设置密码后,之后每次用redis-cli操作都要先用AUTH命令验证身份,客户端连接也需要配置密码。
appendonly参数默认是no,如果设为yes,Redis会开启AOF持久化,把每次写操作记录下来到appendonly.aof文件中。save指令配置了RDB快照的触发条件,默认配置已经包含了save 900 1、save 300 10、save 60 10000这几个策略。本地开发时,如果你不太关心断电丢失最近几秒的数据,保持默认即可;如果涉及需要长期保留数据的学习项目,建议把appendonly改成yes,可靠性会好很多。
3.3 启动验证与连接测试
配置完成后,打开命令行窗口,切换到Redis解压目录,执行:
cd D:\Redis redis-server.exe redis.windows.conf窗口会输出Redis的版本信息、运行模式、监听端口,以及一段经典的ASCII艺术图。看到The server is now ready to accept connections on port 6379这行日志,就说明服务已经起来了。此时不要关掉这个窗口,它是Redis的前台运行进程,窗口一关服务就停了。
再开一个命令行窗口,执行:
cd D:\Redis redis-cli.exe -h 127.0.0.1 -p 6379如果看到127.0.0.1:6379>这样的提示符,说明连接成功。输入ping,服务端回应PONG,就表示这个Redis环境已经正常工作了。此时可以试试最简单的读写操作:
set hello world get hello输入后,get hello应该返回"world"。看到这个结果,环境搭建的核心环节已经走通了。
3.4 注册为Windows服务
每次手动开个命令行窗口确实有点原始。更省事的办法是把Redis注册为Windows服务,让它在系统启动时自动运行,并且一直在后台跑着。以管理员身份打开PowerShell或命令提示符,执行:
cd D:\Redis redis-server.exe --service-install redis.windows-service.conf --service-name Redis执行成功后,在Windows服务管理器(Win+R输入services.msc)中就能找到名为Redis的服务。默认状态下服务不会立刻启动,需要手动启动一次,或者执行:
redis-server.exe --service-start --service-name Redis启动之后,服务状态变为“正在运行”。这样哪怕你关机重启,只要服务没被手动停止,Redis会自动随系统启动,不用再操心每次开电脑手动开服务了。
这里有几个实际操作时容易搞混的点,我单独拎出来说。第一条,注册服务时用的配置文件和手动启动用的配置文件不一样,我之前有次手动启动改了redis.windows.conf里的密码,结果服务启动后密码一直不对,排查了一圈发现服务加载的是redis.windows-service.conf,改错文件了。如果你打算用服务方式运行,后续所有配置都统一改redis.windows-service.conf,避免两个文件配置不一致带来的混乱。第二条,如果服务已经注册过,你想重新注册覆盖配置,需要先执行redis-server.exe --service-uninstall --service-name Redis把旧服务移除,再重新安装,否则会报服务已存在。第三条,卸载服务前记得先停止服务,不然会提示服务正在运行无法删除。
4. 可视化客户端选型与连接实操
4.1 为什么需要可视化工具
刚搭建好环境时,用redis-cli敲命令确实能完成所有操作,但当你开始往Redis里写入几十上百个键值对,或者研究哈希、列表、集合这些复杂数据结构时,纯命令行看数据简直是种折磨。尤其是查看某个key的剩余过期时间、查看某个哈希里的全部字段、对比不同环境的缓存数据,一个可视化界面能节省大量时间。这也是为什么每个正经Redis教程都绕不开可视化客户端这一环。
可视化客户端的核心价值在于:直观查看所有key列表和数据结构、支持按前缀筛选key、查看value的具体类型和内容、查看key的TTL和内存占用、图形化操作增删改查。这些能力在调Bug、验证缓存逻辑、查数据边界时特别好用。
4.2 主流的Windows客户端怎么选
目前Windows平台常见的Redis可视化客户端有几个阵营,我逐个说下实际体验。
Redis Desktop Manager(简称RDM)是老牌选手,界面成熟、功能全面,支持Windows、macOS、Linux,社区口碑一直不错。但它从2022年起改成了订阅制,免费版功能退回到了很老的状态,只能连单机、不能看统计数据,商用还得付授权费。如果不是公司统一购买,个人开发者用免费版会觉得越用越憋屈。它的社区分支AnotherRedisDesktopManager维护得还可以,但功能迭代也慢下来了。
RedisInsight是Redis官方推出的可视化工具,最大的优势是跟着Redis版本走,兼容性最好,而且完全免费。界面风格偏现代,对Redis的模块功能和新技术支持最好,比如支持RedisJSON、RedisSearch、RedisGraph这些模块的可视化操作。不过它启动时要访问官方下载CRDT库文件,网络不好的环境下首次启动会卡在加载页面,这个体验有点烦。
还有一个轻量级的选项是redis-cli的文本交互工具,如果你只是临时看个数据,不装任何GUI也没问题。我个人目前的主力是RedisInsight,兼容性和免费这两条就能覆盖绝大多数使用场景。至于有人推荐的TablePlus、Navicat里的Redis模块,它们本来就不是专注做Redis的,功能深度和复杂数据结构展示上差点意思。
4.3 连接配置完整步骤
以RedisInsight为例,第一次打开后按下面几步操作即可完成连接。
第一步,在主界面点击Add Redis Database按钮。第二步,选择Standalone模式,Connection Type用默认的TCP。第三步,填写Host为127.0.0.1,Port为6379,Database可以保持0。第四步,如果你在配置文件里设置了requirepass,需要在Password字段填上对应的密码,没有设置就留空。第五步,点击Add Redis Database完成创建。
如果连接成功,左侧列表会出现你添加的Redis连接,展开后能看到这个实例的所有数据库,默认是db0。点进db0后,你可以在工具栏上执行命令、查看全部key、按类型过滤数据、查看某key的TTL和内存占用。如果你设置过Redis密码,连接测试时填错密码会看到ERR Client sent AUTH, but no password is set这种误导性很强的报错,看着像没设置密码,实际上是密码不匹配,需要注意区分。
4.4 连接失败时先看这几处
可视化工具连不上的问题,多半不是工具问题,而是服务本身的状态问题。第一,确认Redis服务还在运行,用redis-cli.exe ping验证一下,如果返回PONG说明服务正常,那就是工具配置问题。第二,确认端口没有被防火墙拦截,Windows有时会弹防火墙提示,如果不小心点了取消,后面所有外部连接都会被拦。第三,确认你填写的Host和Port和Redis实际监听的一致,不要在可视化工具里自己脑补端口。
还有一个小细节,如果你在配置里把bind改成了0.0.0.0,那监听地址就是所有网卡,本机连的时候填127.0.0.1还是局域网IP都可以连上。但如果你不改bind,只改protected-mode是不行的,别问我为什么知道,我花了大半天才意识到这个问题。
5. 核心数据类型与常用命令实操
5.1 五大数据类型速览
Redis之所以叫Redis而不是叫"简单缓存服务器",就是因为它不是一个只会存字符串的kv存储,它还支持多种复合数据结构。这五种基本类型是所有Redis应用的地基:String(字符串)、Hash(哈希)、List(列表)、Set(集合)、Sorted Set(有序集合)。
这五种类型各有各的典型应用场景。String适合存缓存对象、计数器、session,还能用setnx实现分布式锁。Hash适合存对象属性,比如用户信息、商品信息,字段可以单独修改,不用整个序列化反序列化。List适合做消息队列、时间线列表,左push右pop就能实现FIFO队列。Set适合做去重、标签、好友关系这类场景,还能做交集并集运算。Sorted Set适合做排行榜、优先级队列,每个成员带一个分数,按分数自动排序。
理解这五种类型还有一个重要角度:它们不是独立存在的抽象数据格式,而是RDB快照和AOF日志里真正落盘的对象编码方式。比如同一个String类型的数据量小时用int编码,大了用raw编码,Hash和List内部还会有ziplist/quicklist等压缩编码的选择。了解这些底层编码有助于你在内存暴涨时判断是该优化数据结构还是该清理无用的key。
5.2 String与Hash的实际操作
先看String类型,这是最基础也是用得最多的。打开redis-cli,做以下操作:
set user:1001 '{"name":"tom","age":30}' get user:1001 incr page:view incrby page:view 10 setex token:1001 3600 abc123 ttl token:1001set简单设置字符串值,get获取值,incr和incrby实现原子自增。这里要注意setex是带过期时间的设置,后面跟着3600是过期秒数,用来做缓存限时数据特别合适。ttl查看key的剩余存活时间,返回-1表示永不过期,返回-2表示key不存在。
Hash类型适合存结构化对象,操作命令是hset、hget、hgetall这些:
hset user:1002 name "jerry" age 25 city "beijing" hget user:1002 name hgetall user:1002 hincrby user:1002 age 1hgetall会把Hash里的全部字段和值都列出来,做调试时特别好用。hincrby可以对Hash里的数字字段做原子自增,比如记录用户积分、点击次数,一点问题没有。Hash和String一个关键的差异在于内存占用和操作粒度:用String存整个对象,每次更新任意一个字段都要get、改、set一轮;用Hash存对象,单独更新某个字段只需要hset一个字段,网络开销和序列化开销都小得多。
5.3 List、Set与Sorted Set的使用场景
List类型有push和pop两类操作,左右两个方向都能操作:
rpush queue:task task1 task2 task3 lrange queue:task 0 -1 lpop queue:task llen queue:taskrpush从右侧推入元素,lpop从左侧弹出元素,组合在一起就是先进先出的队列语义。lrange 0 -1可以一次查看所有元素,开发调试时避免一个个get。这种操作方式在做异步任务队列时很常见,生产者rpush,消费者lpop,简单实用。
Set类型适合做唯一性集合:
sadd fruits apple banana orange smembers fruits sismember fruits apple sinter tag:python tag:backend scard fruitssmembers列出所有成员,sismember快速判断一个成员是否在集合中,时间复杂度是O(1)。sinter可以做两个集合的交集,比如找出同时带python和backend标签的文章ID。scard返回集合元素个数。这类操作在推荐系统求共同喜好、权限系统求角色交集时经常用。
Sorted Set比Set多了一个score概念,自动按score排序:
zadd leaderboard 100 player1 95 player2 88 player3 zrange leaderboard 0 -1 zrevrange leaderboard 0 -1 withscores zincrby leaderboard 10 player2 zrank leaderboard player2zadd添加带分数的成员,zrange按分数从低到高排列,zrevrange从高到低,zincrby给某个成员加分,zrank查看排名。排行榜、积分榜这种需求,用Sorted Set是天然适配的,不需要自己在业务代码里实现排序逻辑。
5.4 数据过期与持久化验证
开发过程中,你还需要理解Redis的过期删除和持久化机制,这部分直接影响程序行为。
过期删除有两种机制共同作用。第一种是惰性删除,访问到某个key时发现它已过期,才真正删除它。第二种是定期删除,Redis后台每100毫秒扫描一批设置了过期时间的key,把过期的删掉。这两种方式配合,在实际使用中能保证过期key最终都会被清理,但在TPS高峰时可能短暂存在已过期但还没被删掉的key,这个语义需要注意。
持久化方面,RDB模式是把内存中的全部数据快照写入dump.rdb文件,重启时加载这个文件恢复数据。AOF模式是把每次写操作以追加日志的方式记录到appendonly.aof,重启时重放这些日志恢复数据。两者都打开时,Redis启动会优先加载AOF文件,因为AOF通常情况下数据完整性更好。在本地方便起见,建议至少打开RDB快照,避免电脑重启后数据全空。设置在配置文件里就是:
save 900 1 save 300 10 save 60 10000 appendonly yes appendfilename "appendonly.aof"我有一回在Windows上做了很多数据实验,配好各种key之后嫌麻烦没开持久化,结果系统自动更新重启了一次,再启动Redis,所有数据全没了,等于白忙活半天。所以提醒各位,本地做学习实验时可以不加持久化配置,但只要是正经功能开发,持久化的开关动手前就先想清楚。
6. 常见问题与排查技巧实录
6.1 端口占用引发启动失败
场景描述:执行redis-server启动时,窗口报错Could not create server TCP listening socket *:6379: bind: No error或者Address already in use。说白了就是6379端口已经被某个进程占了,Redis想监听它却绑定不了。
排查方法:在命令行里执行netstat -ano | findstr 6379,查看占用6379端口的进程PID。然后打开任务管理器,找到对应PID的进程,确认是什么程序。如果确实被其他程序占用了,有两个选择:一是关掉那个程序释放端口,二是修改Redis配置文件里的port参数,换成6380或者其他空闲端口。
这个问题的升级版是这样的:当你用redis-cli.exe连Redis时,明明连上了但执行操作时报UNKILLABLE之类怪异的错误,那有可能是连上了一个被伪装成Redis的恶意服务。本地开发时建议定期用redis-cli.exe info server看返回的redis_version是否和预期一致。
6.2 服务模式下配置文件不生效
场景描述:已经把Redis注册为Windows服务,但是修改redis.windows-service.conf里的配置,比如改了密码、改了持久化开关,重启服务之后配置就是不生效。这个我记得很清楚,因为我自己就犯过这个错误:手动启动时加载的是redis.windows.conf,而服务加载的是redis.windows-service.conf,两个文件不一致导致改了那边都没用。
排查思路就是先分清你的运行模式。如果用redis-server.exe redis.windows.conf手动启动,所有配置都改redis.windows.conf;如果是通过Windows服务运行的,所有配置都改redis.windows-service.conf。改完配置后,重启服务使配置生效:
redis-server.exe --service-stop --service-name Redis redis-server.exe --service-start --service-name Redis修改配置要不要重启服务这个问题,答案是:改端口、绑定地址、持久化模式、密码这几类关键参数,必须重启服务才能生效,因为这些参数是在服务启动时一次性读取的。但如果你用CONFIG SET命令在线改某些参数,可以不重启,但这只是临时生效,重启后就会恢复配置文件里的值。
6.3 可视化工具连接超时
场景描述:RedisInsight连接本机Redis时报连接超时,但redis-cli能正常连接和操作。这种“一半能连一半不能连”的状态最让人蒙圈。
按顺序排查以下五项,99%的情况能覆盖。
第一步,检查Redis是否还在运行。第二步,确认Redis配置里的bind参数。如果bind只写了127.0.0.1,那只有环回地址能连;如果bind写的是0.0.0.0,那所有网卡都能连。可视化工具里填的Host要对应上。第三步,检查配置文件里的protected-mode参数。如果你的bind不是127.0.0.1,但protected-mode是yes,非本机来源的连接会被拒绝。第四步,检查Windows防火墙,确认6379端口是否有入站规则放行,可以在防火墙高级设置里新建入站规则,允许TCP端口6379连接。第五步,检查可视化工具填写的Port和Redis实际监听的端口是否一致。
还有一个容易忽略的点:Redis 5.0版本之后,默认的认证行为发生了变化。如果你的requirepass没有设置,某些版本的客户端会默认发起AUTH请求,导致报错ERR Client sent AUTH, but no password is set。这时只需要在可视化工具中把密码字段清空,重新连接即可。
6.4 中文乱码与编码问题
场景描述:在Redis中存入中文,用redis-cli查看时显示\xe5\xbc\xa0...这类转义序列,或者可视化工具里显示为乱码。
这个问题的根源是Redis本身保存的并不是纯文本,而是经过二进制安全处理的字节序列,中文按照UTF-8编码被保存了下来。redis-cli默认以转义形式显示非ASCII字符,所以看起来像乱码,实际上数据内容是正确的。处理方法是在启动redis-cli时加上--raw参数:
redis-cli.exe -h 127.0.0.1 -p 6379 --raw加了--raw之后,查询key时就能直接看到中文原样输出。如果连--raw都不能解决,那就是写入时编码就不是UTF-8,需要检查上游程序入库时的字符集设置。可视化工具一般都能正确解析UTF-8,遇到乱码先确认数据源,别急着删数据。
6.5 崩溃退出与数据丢失处理
场景描述:Redis进程突然崩溃,重启后数据丢失,或者启动时直接报错退出。
先看崩溃日志。Windows上Redis的日志默认输出到控制台,如果你是用服务方式运行,日志在Windows事件查看器里能找到。还有一种常用做法是手动启动一次,把窗口输出信息留存,看有没有FATAL级别的错误信息。常见的崩溃原因有几个:内存不足,Redis是内存型数据库,系统内存耗尽会导致进程被系统强制杀掉;配置语法错误,比如conf文件里出现了不支持的参数或者格式错误,Redis会在启动时直接拒绝加载并报错退出;数据文件损坏,比如dump.rdb或appendonly.aof因为断电或磁盘故障损坏了,Redis启动时如果加载损坏的数据文件会失败。
如果是因为dump.rdb损坏导致启动失败,可以先手动把dump.rdb改名备份,再启动Redis,让它生成新的快照文件。如果AOF文件损坏,可以用配套的redis-check-aof.exe工具修复:
redis-check-aof.exe --fix appendonly.aof执行后会提示是否截断不完整部分,选择确认,一般能修复成功。但是要注意,修复过程会丢弃损坏位置之后的记录,修复完尽快做一次全量备份更稳妥。
6.6 慢查询与性能自查
本地环境虽然压力不大,但学会自查Redis性能是个好习惯。Redis提供了慢查询日志,默认阈值是10毫秒。在redis-cli里执行:
slowlog get 10 slowlog len slowlog reset当某个命令执行耗时超过阈值,它就会被记录到慢查询日志中。本地开发时如果你发现某些操作频繁触发慢查询,优先检查命令本身是否不合理,比如用keys *全量扫描key列表,这在key数量大时是性能杀手,正确做法是用scan 0 MATCH user:* COUNT 100这种游标式增量遍历。还有一个常见的性能坑是使用了过大的value,比如把几MB的日志字符串硬塞进一个String key里,这类操作会把网络传输和内存分配拖到很慢。
7. Windows环境定期维护与进阶拓展
环境跑起来只是第一步,后面怎么稳定地用才是关键。我把自己维护Windows Redis环境时积累的几个小习惯列出来,给各位做个参考。
日志文件的清理。Redis运行一段时间后,日志文件可能会变得很大。Windows服务模式下,尽量避免直接删除日志文件,这会破坏文件句柄,进程可能无法继续写入。更稳妥的做法是停止Redis服务,删除旧日志,再启动服务,让Redis重新创建日志文件。
配置文件的备份。redis.windows-service.conf这个文件是你整个环境的配置中枢,建议在编辑前先复制一份带日期后缀的备份。我吃过一次亏,改配置时删掉了某个关键参数又没记住原来的值,最后只能重新下载默认配置再逐项调回来。
重启后的数据验证。每次Windows更新自动重启后,建议先检查Redis服务是否正常启动,再用redis-cli执行一个简单的get操作确认数据能正常读取。如果发现数据不见了,第一时间检查持久化文件是否还在,如果文件还在但数据为空,多半是配置里持久化开关没打开。
进阶拓展方面,有几个方向值得往下挖。主从复制可以实现一主一从的高可用结构,在Windows上完全可以搭两个Redis实例,用slaveof命令或者配置文件里的replicaof参数把从节点指向主节点。哨兵模式可以在主节点挂掉时自动把从节点提升为主节点,这是生产级高可用的入门形态。集群模式则是把数据分片到多个Redis节点上,实现水平扩展。这些进阶内容都依赖于先把单机环境搞明白,所以底子扎实了再往上走会顺很多。
我个人在实际使用中的体会是,Windows环境搭建Redis这件事,门槛其实就集中在取舍和排查两件事上。选对版本、用对配置,十分钟就能跑起来;但日常使用中各种奇怪的问题,几乎全是配置文件和端口之间的错配导致的。与其急着去啃命令大全,不如先把配置文件的每个参数吃透,再把本文提到的那几个排查路径走通,后面用起来真的会顺心很多。
最后分享一个小技巧:把redis-cli.exe的目录加到系统环境变量的Path里,这样以后想执行redis-cli、redis-server,不用每次cd到安装目录才可以,在任意目录下敲命令就能直接用。Windows下这招还是实测下来很舒服的。