企业官网建设流程全解析

以前我在 Win10 下装 Redis 时，第一反应是去搜索引擎找一个“redis 下载”的压缩包，解压后双击 redis-server.exe，结果窗口一闪而过，要么报个错要么直接没反应。后来折腾多了才发现，在 Windows 环境下装 Redis 不是不可以用，但官方其实从来没有正式支持过 Windows，这里面的版本来源、服务注册、配置路径、可视化工具选型，处处是坑。

这篇文章我会把我自己在 Win10 下安装、配置、连接 Redis 的完整过程，以及踩过的坑，写成一套可以直接照着做的实操记录。适合刚接触 Redis、想在 Windows 上跑一个本地环境的开发者，也适合那些已经装上 Redis 但连接不稳、服务老挂、不知道怎么配持久化和密码的人。文章会覆盖安装方式选择、服务注册、客户端连接、常见报错排查，以及装完之后怎么往分布式锁、缓存治理这些实战方向靠，一次讲透。

1. 先搞清楚：Windows 上的 Redis 到底是个什么来头

1.1 官方不维护 Windows 版，这话得先放前面

很多第一次装 Redis 的人都会产生一个误会：Redis 官网写着支持 Linux、macOS，怎么就没有 Windows？事实是，Redis 官方明确表示不提供 Windows 版本，Windows 下的 Redis 一直靠社区移植和第三方发行版顶着。你从网上搜出来的那些“Windows 版 Redis 下载”，基本都来自这么几个渠道：微软团队早期维护的移植版、社区开发者维护的独立移植项目，还有一些商业化的兼容实现。

这个前提为什么重要？因为它直接决定你装的是不是“正主”。我之前装过一个微软老仓库里的版本，版本号停在 3.2，表面上看 Redis 能跑，redis-cli 也能用，但后来想用 5.0 才引入的 Stream 类型做消息队列，命令根本不认识。也就是说，你装了一个“Redis”，但这个 Redis 可能是好几年前的老古董，功能不完整，后续维护也指望不上。

在动手之前，建议先花两分钟想清楚自己的需求：如果只是本地写 demo、测试基本数据结构，随便一个能跑的版本都行；如果是要模拟生产环境、跑分布式锁、做缓存中间件，那版本和部署方式就得认真选。我见过不少人直接在 Win10 上装了老版本，写业务代码用到某个新命令时才发现服务端不支持，最后只能推倒重来。

1.2 版本盘点与选型建议

我把自己实际接触过的几种 Windows 下运行 Redis 的途径整理了一下，各有各的适用场景：

我个人在 Win10 上的日常开发首选是社区维护的 5.0.10 原生移植版。原因很简单：它是独立的 Windows 可执行程序，不依赖额外虚拟化，启动快，注册成服务也方便，而且 5.0 这个版本已经覆盖了绝大多数业务场景要用的功能。如果哪天公司生产环境升到 Redis 7，我才会考虑切到 WSL 或 Docker 去对齐。

补充一句，WSL2 里装官方 Redis 其实也不复杂，Windows 商店装好 WSL 系统，进去执行几条命令就能把 redis-server 拉起来。但如果你只是为了本地连个缓存，为了跑个 set/get，为了看看可视化客户端长什么样，真没必要为了它单独开一个 Linux 子系统。工具是服务于需求的，别为了装而装。

1.3 热点玩法对安装有哪些隐性要求

你去看搜索引擎上跟 Redis 相关的热词，除了“redis 安装教程”“redis 下载”之外，还有“redis 分布式锁”“redis 缓存治理”“redis 做中间件”。这些听起来高级的词，背后其实都对 Redis 服务端版本有隐性要求。

举个例子，分布式锁最基础的写法是SET key value NX EX 秒数，这个命令语法在 Redis 2.6.12 就有了，老版本也能用。但你真要让锁在高并发下稳定，往往还需要用 Lua 脚本保证“检查和删除”的原子性，或者干脆集成 Redisson 这种客户端，这时候客户端跟服务端的协议兼容就得注意。再比如缓存治理里经常提到的“大 Key 删除”，Redis 4.0 之后才有UNLINK，老版本只能DEL，一删就可能阻塞主线程几秒钟。又比如消息队列场景常用的 Stream，那是 5.0 才加入的数据类型。

这些需求叠在一起，结论就非常清晰：别去碰 3.2 那批老版本。我最初的安装环境就是一个老移植版，后来为了做分布式锁的 demo，服务端虽然能跑但很多客户端新特性不支持，排查了半天才发现是服务端版本太低。版本选对，后面省一大堆事。

2. 安装实操：从解压到跑通 redis-cli 的一条龙

2.1 下载、解压、目录整理

选定社区移植的 5.0.10 版本后，第一步是把 zip 包下下来。解压的时候我强烈建议你放到一个不带中文、不带空格的目录，比如C:\Redis。这个细节很多人不在意，但后面注册 Windows 服务、写配置文件路径、定位日志文件时，路径有空格会让命令解析变得非常难受，尤其是服务注册那一步，引号套引号很容易翻车。

解压之后你会看到一堆文件，常见的几个要认识一下：

• redis-server.exe：服务端主程序，跑 Redis 就是跑它。
• redis-cli.exe：命令行客户端，用来连接、发命令、验证状态。
• redis-benchmark.exe：性能压测工具，平时用不上，测试时可以玩。
• redis.windows.conf：标准配置文件，里面参数和注释都很全。
• redis.windows-service.conf：专门给 Windows 服务模式准备的配置文件，内容更精简。

我习惯把redis.windows.conf复制一份改名为redis.conf，日常改动都写在redis.conf里，保留原始文件当作备份和对照。这样万一改坏了，随时拿原文件比一眼就能看出哪里有问题。

2.2 启动服务器并验证连通

第一次启动，直接在 PowerShell 里进入C:\Redis，执行：

.\redis-server.exe redis.conf

正常情况下你会看到右下角出现经典的 Redis ASCII 图案，下面标注端口6379，Redis 版本号，进程 ID 等信息。这个窗口就是前台进程，关掉窗口 Redis 就停了，所以它只适合临时测试。

接着再打开一个新的终端窗口，验证连接：

.\redis-cli.exe ping

如果返回PONG，说明服务端起来了，客户端也通上了。继续做两步读写测试：

.\redis-cli.exe set hello world .\redis-cli.exe get hello

能返回world，你的 Redis 已经可以正常干活了。如果不想用默认配置，也可以直接带参数启动，比如.\redis-server.exe --port 6380，这样会把监听端口改成 6380。命令行参数优先级高于配置文件，配置文件里的设置又高于编译默认值，这个顺序是 Redis 一贯的行为，后面排查问题会用到。

2.3 几个我改过的高频参数

把 Redis 跑起来很简单，但要在 Windows 下用得顺手，配置文件里有几个参数我建议当时就改掉。每个参数背后都是一个实际问题，不是随便改着玩。

端口port：默认 6379，本机没冲突就不用动。如果本机有别的服务占了，改成 6380、6381 都可以。

绑定地址bind：默认是127.0.0.1，只允许本机连接。如果只想本机访问，保持默认是最安全的。如果虚拟机、WSL、局域网里的其他机器需要访问这台 Redis，就得改成0.0.0.0或者其他具体内网地址。这个改动有一个隐藏风险，后面在排查连接问题时我会细说。

最大内存maxmemory：Windows 环境下的 Redis 移植版对系统内存的占用管理不如 Linux 原生版那么精细，如果你跑测试时塞了大量数据，Redis 进程的内存可能一直涨而不主动释放。我本地一般设成512mb，顶多加到1gb，这样至少不会把开发机拖垮。

持久化appendonly：本地测试时数据丢了无所谓，但如果 Redis 里放了需要保留下来的数据，必须把appendonly yes开起来。默认是 no，意味着重启之后所有数据归零。

日志文件logfile：Windows 版如果不配置 logfile，日志会打印到控制台。服务模式下没有控制台，日志去哪了就得靠猜。我会显式配置logfile "redis-server.log"，这样排错时直接看文件。

密码requirepass：本地开发可以暂不设密码，但你要是改了bind 0.0.0.0或者要允许局域网访问，那就必须设密码。Redis 的protected-mode机制会在“没有密码 + 非本机访问”的组合下直接拒绝所有外部请求，这个我后面专门讲。

3. 把 Redis 变成 Windows 服务：进程级自启的正确姿势

3.1 注册服务，告别每次手动开窗口

前台启动 Redis 有个很烦的问题：电脑重启后你不会记得开它，手动开一个黑窗口放着又难受，而且窗口一旦被误关 Redis 就没了。Windows 下有正解：把 Redis 注册成系统服务。

这个操作不需要额外下载 NSSM 之类的工具，redis-server.exe本身就集成了服务管理能力。以管理员身份打开 PowerShell，进入 Redis 目录，执行：

.\redis-server.exe --service-install redis.windows-service.conf --service-name Redis --loglevel verbose

注意这里我特意用了--service-install而不是直接双击运行。参数里的redis.windows-service.conf是服务模式专用配置，--service-name Redis可以换成你想要的名字，--loglevel verbose是为了让日志更详细，注册出错时容易定位。

注册完之后执行启动：

.\redis-server.exe --service-start --service-name Redis

然后验证：

.\redis-cli.exe ping

返回PONG就成了。打开 Windows 的“服务”管理窗口（Win+R 输入services.msc），你能看到名为 Redis 的服务，此时它的状态应该是“正在运行”。如果想让它开机自动跑，在服务属性里把启动类型设为“自动”即可。

以后不再需要前台窗口了，Redis 会在系统后台安静运行，关机重启后也会跟着起来。这一套做完，你才真正拥有了一个“Windows 原生态”的 Redis 环境。

3.2 服务模式下配置文件的选择陷阱

很多人注册服务时随手用了redis.windows.conf，运行起来发现日志不写、持久化文件不知道存哪，甚至在服务里显示启动失败。这里我要把两个配置文件的定位讲清楚。

redis.windows.conf是带完整注释的“标准文档型”配置，所有参数都写在里面，适合手动调优和阅读。redis.windows-service.conf是精简配置，去掉了大量说明性注释，保留了服务模式下最需要关注的核心参数。两者本质都是 Redis 配置文件，格式上完全兼容，用什么文件名启动都行，没有魔法限制。

关键问题在于：服务模式的工作目录和行为跟前台模式不一样。如果你不显式配置dir参数，Redis 的持久化文件dump.rdb和 AOF 文件可能生成在系统目录或服务的工作目录里，等到你要备份、迁移时才想起来去找文件，往往已经找不到了。所以我在注册服务之前，会把redis.windows-service.conf里的dir明确改成C:\Redis，确保所有数据文件落在一个我随时能找到的位置。

另外，服务启动失败时，日志是最直接的线索。打开文件资源管理器，进入 Redis 目录，看是否有redis-server.log生成，再用记事本打开它，Config 解析错误、端口占用、权限不足都会写在里面。Windows 服务的排错比前台进程麻烦，因为你根本看不到控制台输出，日志文件就是唯一的窗口。

3.3 服务管理常用命令与“杀毒软件拦截”这个坑

服务注册完成之后，日常管理我一般直接用命令行，比点服务管理界面快得多。下面这几个命令我几乎会背：

# 停止 Redis 服务 .\redis-server.exe --service-stop --service-name Redis # 启动 Redis 服务 .\redis-server.exe --service-start --service-name Redis # 卸载 Redis 服务 .\redis-server.exe --service-uninstall --service-name Redis # 重启服务（先停止再启动等效操作） .\redis-server.exe --service-stop --service-name Redis .\redis-server.exe --service-start --service-name Redis

如果你卸载服务时提示“服务不存在”或者“没有权限”，先确认你是不是以管理员身份运行的 PowerShell，再确认服务名有没有拼错。

还有一个我在这里必须单独说一说的坑：Windows 自带的安全中心和各类杀毒软件可能会拦截 redis-server.exe 写入服务注册表、监听端口的操作。遇到过一种情况，服务注册命令执行完提示成功，但服务列表里就是找不到，或者启动后马上被“隔离”。遇到这种情况，不要急着怀疑命令，先看一眼安全软件的隔离记录。如果确实是误报，把C:\Redis目录加入信任区再重新注册。这不是 Redis 本身有问题，是 Windows 安全机制对“可执行程序创建系统服务”这个动作天生敏感。反正我的经验是，装 Redis 之前先把安全软件对 Redis 目录的监控关掉，或者准备好白名单，能省不少雷。

4. 可视化客户端与常见连接排错

4.1 客户端选型：RDM 和 Another Redis Desktop Manager

Redis 装好之后，很多人下一步就是找一个可视化客户端，毕竟盯着命令行敲keys *在数据多的时候会让人崩溃。市面上最常用的两个，我分别说下实际体验。

第一个是 Redis Desktop Manager，缩写 RDM。早年它是免费的，后来版权方调整了商业模式，新版本变成了付费授权。很多人下载 RDM 之后发现是试用版，用几天就弹窗，体验很差。第二个是 Another Redis Desktop Manager，缩写 ARDM，是开源社区对 RDM 的替代项目，面向 Windows、macOS、Linux 都有安装包，基础功能像 key 浏览、增删改查、命令行终端都有，日常开发完全够用。我现在固定在用 ARDM，没有授权提示，连接管理也顺手。

在 ARDM 里新建连接，需要填四样东西：连接名（随便起）、地址（本机默认 127.0.0.1）、端口（6379）、密码（如果设置了 requirepass 才填，没设置就留空）。点“测试连接”显示成功后再保存。界面左侧会列出所有数据库编号，默认 Redis 有 16 个库（0 到 15），库下面就是一个个 key，点击可以看到 key 的存储类型和具体内容。这个工具的核心价值在于：当你面对几十上百个 key 时，可视化界面能快速知道里面存了什么东西，而不用记一堆命令。

4.2 先用 redis-cli 验证，再上客户端

我每次遇到“客户端连不上”的问题，第一反应永远不是去改客户端设置，而是先用 redis-cli 验证服务端本身是否健康。这个顺序能帮你迅速切分问题归属：如果 redis-cli 也连不上，问题在服务端，去排查 Redis 进程、端口、配置；如果 redis-cli 能通，只有客户端不通，问题在客户端的连接参数或防火墙对某种程序的拦截。

带密码时用 redis-cli 连本机 Redis，命令是这样的：

.\redis-cli.exe -h 127.0.0.1 -p 6379 -a 你的密码 ping

注意-a会把密码直接暴露在命令行里，本机开发用一下无妨，生产环境千万别这么干，可以用REDISCLI_AUTH环境变量代替。如果 redis-cli 返回 PONG，服务端确认没问题，此时再去客户端里排查，思路就清晰多了。

4.3 “连接超时”和“拒绝连接”的完整排查链路

我在公司帮同事处理过不少 Redis 连接问题，报错五花八门，最多的两个：一是Connection refused，也就是连接直接被拒；二是比如 Java 环境里出现的io.lettuce.core.RedisCommandTimeoutException: Redis command timed out，命令执行超时。这两个症状背后可能的原因差异很大，我列一个自己的排查顺序，按顺序走基本都能找到根。

第一查进程。先在任务管理器里看 redis-server.exe 是否在跑，服务模式下还要去 services.msc 看服务状态是“正在运行”还是“已停止”。服务停了你连什么都白扯。

第二查端口。在 PowerShell 里执行：

netstat -ano | findstr 6379

能看到监听记录就说明端口是开着的，看不到就说明 Redis 没在监听。顺着 PID 再去任务管理器确认这个进程是不是 redis-server。

第三查防火墙。Windows 防火墙默认不会放行陌生程序的入站连接，6379 端口很可能被悄悄拦掉了。开发机可以临时加一条入站规则放行 TCP 6379，如果你公司网络策略严格，记得事后确认规则是否有安全审查要求。这一步做完，Connection refused类问题基本能解决。

第四查绑定地址和密码。配置文件的bind 127.0.0.1意味着只有本机能连，局域网机器连进来自然会被拒。你把 bind 改成0.0.0.0之后，没有设置密码而protected-mode又是默认开启时，Redis 会拒绝来自非本机的连接，这是保护机制在起作用。正确做法是：允许外部访问时，必须同时设置一个足够强的密码。

第五查客户端超时参数。这个比较隐蔽，尤其是“连接能建立，但大 key 查询或慢操作时超时”。Spring Boot 项目里如果你用的 Lettuce 客户端，连接池和超时时间配置得不合理，Redis 侧只是执行慢了一点，客户端就已经超时抛异常。以 Spring Boot 3.x 为例，配置文件里这样调：

spring: data: redis: host: 127.0.0.1 port: 6379 password: 你的密码 timeout: 3s lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0

注意 Spring Boot 2.x 用的是spring.redis.*，3.x 改成spring.data.redis.*，网上很多老帖子还在用旧写法，照着抄容易踩版本差异的坑。真遇到超时问题，先把 timeout 适当调大并确认连接池 max-active 足够线程并发，再深入排查 Redis 侧是否有慢查询。Redis 自身提供的SLOWLOG GET命令可以看到慢命令明细，这个命令的用法值得单独记一下。

5. 装完别急着用：密码、持久化和日常防坑

5.1 requirepass 与 protected-mode 的配合

很多人觉得“我 Redis 只在本机跑，设密码没必要”，这个想法我理解，但不太认同。Windows 开发机经常连着公司局域网甚至公网，Redis 默认端口 6379 很容易被扫描器发现。设密码这行操作并不复杂，却能直接挡住一大批“顺手试一下默认配置”的扫描者。

配置里加一行：

requirepass yourStrongPassword

保存后重启 Redis 服务。之后连接必须带密码，命令行交互方式是先进入 redis-cli，再执行AUTH 你的密码。如果嫌每次交互麻烦，可以像前面说的那样用redis-cli -a 密码，或者配置环境变量。可视化客户端则在连接配置里填密码。

同时要理解protected-mode这个参数。当它是默认的 yes 时，如果 Redis“没有配置密码”并且“监听了非本机网卡”，那么任何从外部来的连接都会被拒绝。这不是 bug，而是安全兜底。如果你确定要在局域网里供别人连，必须把密码设置好，然后外部访问才被允许。反过来，如果你只想本机使用，bind 保持 127.0.0.1 就是最简洁、最安全的组合，密码仍然建议设置，因为本机其他恶意进程也有可能通过回环地址连你的 Redis。

5.2 RDB 与 AOF：重启不丢数据的底线

Redis 默认会把数据定期以快照形式写到磁盘，这就是 RDB 持久化，默认配置是这样：

save 900 1 save 300 10 save 60 10000

三行的意思是：900 秒内有 1 次写操作就存盘，300 秒内有 10 次写操作就存盘，60 秒内有 10000 次写操作就存盘。它的问题在于，如果 Redis 在两次快照之间崩溃，这段时间的写入会全部丢失。

AOF 则是另一种思路，把每次写操作追加到文件里，重启时通过重放这些操作恢复数据。配置如下：

appendonly yes appendfsync everysec

appendfsync everysec表示每秒把缓冲区的写操作同步到 AOF 文件，性能与数据安全比较均衡，最多丢一秒的写入。如果设成always，每次写入都落盘，最安全但性能损耗也最大。

我的习惯是本地开发直接appendonly yes开着。因为 Windows 下重启系统的频率远高于服务器，你要是没开 AOF，辛苦 set 进去的数据一旦忘了存盘，重启后只剩刚启动时的空数据库，那种感觉经历过一次就再也不想经历第二次。两个持久化机制同时开启时，Redis 启动时会优先用 AOF 文件恢复数据，因为它们更完整。

5.3 maxmemory 与淘汰策略

本地测试时最容易忽略的一个参数是maxmemory。不设的话，Redis 会一直往内存里塞数据，直到把系统内存吃空。我在 Windows 版上遇到过 Redis 进程占用几个 GB、系统响应变慢的情况，原因就是测试脚本往里灌了大量数据没有清理，而 Redis 又没有内存上限。

配置文件里这样设：

maxmemory 512mb maxmemory-policy allkeys-lru

512mb是我本地常用的值，你可以按机器配置调整。maxmemory-policy决定内存满了之后的行为，allkeys-lru表示在所有 key 中按最近最少使用算法淘汰；volatile-lru只淘汰设置了过期时间的 key；noeviction是默认策略，内存满了直接返回 OOM 错误，不再接受写操作。

理解这几个策略的差别很重要。缓存场景用allkeys-lru没有毛病，因为缓存本身就是可以丢弃的数据。但如果你 Redis 里放了订单、商品等不能随便丢的数据，就得慎用 LRU 淘汰，要么用noeviction让写入失败并及时报警，要么这些数据本身就不该住 Redis，该放数据库就放数据库。

5.4 备份、迁移与恢复的土办法

Windows 下做 Redis 备份和迁移，比 Linux 服务器上简单得多，因为整个数据就是几个文件。最常用的备份方式是在 redis-cli 里执行：

.\redis-cli.exe BGSAVE

这个命令会后台触发一次 RDB 快照，生成dump.rdb文件。然后把整个 Redis 目录下的dump.rdb和 AOF 文件复制到备份目录，就可以安心关机了。恢复的方法更直接：停掉 Redis 服务，把备份的dump.rdb放回配置的dir目录，启动服务，数据就回来了。

我在 Windows 上做数据迁移时，会特别注意三个文件的一致性：dump.rdb、appendonly.aof和配置文件里的dir路径。经常有人只拷贝了dump.rdb，却忘了确认目标机器配置的 dir 指向哪里，结果 Redis 启动后在新的路径下找不到旧文件，看起来数据丢了，其实是路径不对。只要你把dir显式写死在一个你熟悉的位置，备份和迁移都只是一顿复制粘贴的功夫。

6. 装完能干什么：从数据类型到分布式锁的进阶

6.1 五种数据类型的落地场景

Redis 装好、服务跑通、客户端连上，接下来的问题就是“这玩意到底怎么用”。Redis 的五个基本数据类型，每个背后都有一批典型场景，我用自己的话给你串一遍。

String类型，最简单也最常用。key 对应一个字符串值，缓存用户登录 token、计数器、验证码都属于它的活。比如INCR article:read:10086就能给文章阅读数 +1，一行命令解决数据库里最容易产生并发瓶颈的计数器问题。

Hash类型，适合存对象。用户信息、商品详情这类结构数据，如果用 String 存，通常要序列化成 JSON 字符串，改其中一个字段就得整体反序列化再序列化，很笨。用 Hash 就能做到HSET user:1001 name "张三"、HGET user:1001 name，按字段读写，更新一个字段不影响其他字段。

List类型，本质是个双向链表。可以从左边推入LPUSH，右边弹出RPOP，实现简单消息队列。BRPOP还能阻塞等待，实现可靠性要求不高的异步解耦。它的操作和命令比专业消息中间件简单，性能好，但复杂路由、消息确认这些高级能力别指望它。

Set类型，是无序集合，自带去重。社交场景里的“共同好友”就非常适合：SINTER user:1001 user:1002直接得到两个人的共同好友。标签系统也可以用 Set，给文章打标签、按标签拉文章列表，都是它的强项。

ZSet类型，有序集合，每个元素带一个分数。排行榜功能直接用 ZAdd 把玩家 ID 和分数推进去，ZREVRANGE就能取出前几名。延时队列也可以靠它实现：Score 存当前时间戳加延时秒数，定时器用ZRANGEBYSCORE把到期的任务取出来处理。

这五类数据结构的区别，用一个简单的总结来记：String 是单个值，Hash 是对象的多个字段，List 是排队处理，Set 是去重视角，ZSet 是带排序规则的集合。

6.2 Redis 做中间件：缓存治理三兄弟

搜“redis 缓存治理”这个热词的人，基本都是在问缓存穿透、缓存击穿、缓存雪崩这三件事。我把这三兄弟用大白话讲清楚。

缓存穿透，指的是请求查询的数据在缓存和数据库里都不存在。你查一个根本不存在的商品 ID，Redis 里没有，每次都落到数据库，数据库也没有，查询毫无意义但请求量巨大。防的办法有三个：一是用布隆过滤器先把不存在的 key 过滤掉，二是对空结果也做短暂缓存，比如set cache:key "" ex 60，三是给参数做合法性校验。我自己常先用“空值缓存”这种最轻量的方案，成本低，效果立竿见影。

缓存击穿，指的是一个非常热门的 key 在过期的一瞬间，大量请求同时打到数据库。热点 key 一旦失效，所有请求都去重建缓存，数据库瞬间扛不住。对策是互斥锁：只放一个请求去数据库重建缓存，其他请求等待缓存重建完成。也可以用“逻辑过期”的技巧，缓存里设置一个业务过期时间字段，读到时发现逻辑过期就异步去刷新。

缓存雪崩，指的是大量 key 在同一时间过期，或者 Redis 直接宕机，所有请求全部涌向数据库。对策是让过期时间随机化，比如每个 key 的过期时间加上随机 1 到 5 分钟；同时做好 Redis 高可用，不能把所有鸡蛋放在一个节点里。

这“三兄弟”是面试和实战都绕不开的问题，把每个场景的原因、现象、对策串成一个完整故事，比背十个零散知识点有用得多。

6.3 分布式锁：SETNX 的正确打开方式

分布式锁是 Redis 在生产环境里最经典的高阶用法。它的核心思路，是让多个应用实例通过 Redis 竞争一个专属 key，谁拿到 key 谁就能安全地执行临界区代码。

正确加锁的命令只有一条：

SET lock:order:10001 唯一标识值 NX EX 30

NX 表示 key 不存在时才能设置成功，EX 30 表示锁的自动过期时间是 30 秒。这个 key 被同一个时刻只有一个请求设置成功，其余请求设置失败，就形成了锁的效果。

我见过不少教程让新手先执行SETNX key value，再单独执行EXPIRE key 30，这是非常危险的写法。因为如果执行 SETNX 之后、执行 EXPIRE 之前进程崩溃了，这个锁永远没有过期时间，所有请求都会被卡死。从 Redis 2.6.12 开始，SETNX 和 EXPIRE 可以合并成一条SET key value NX EX命令，原子性由服务端保证，不用自己拼。

释放锁时也要格外小心。不能直接DEL key，因为如果锁已经超时自动释放，而当前请求还拿着旧标识去删，可能把另一个请求刚设置的锁删掉。正确做法是先用 Lua 脚本比较 value，相等才删除：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

这套“唯一标识 + Lua 校验 + 原子删除”的组合，是分布式锁能够安全工作的核心。实际项目中你甚至可以依赖 Redisson 客户端，它把锁的续期、重试、释放都实现好了，不用自己写 Lua。但理解底层机制对你排查锁失效问题非常有帮助。

6.4 面试题与准备点顺带梳理

搜“redis 面试题”的人多，我也把常见的高频题目串一下，每个给一句关键答案，但面试时最好能展开讲。

第一题，“Redis 为什么快”。答案要点是纯内存操作、单线程避免上下文切换和锁竞争、IO 多路复用。第二题，“Redis 单线程为什么还能支持高并发”。很多人的误区是单线程就慢，其实对于纯内存读写，单线程避免了多线程锁开销，瓶颈在网络 IO，而 IO 多路复用让一个线程能同时管理大量连接。第三题，“RDB 和 AOF 怎么选”。RDB 文件体积小、恢复快，但可能丢数据；AOF 文件更完整，但重放慢、文件大。生产环境经常两者同时开。第四题，“分布式锁怎么实现”。把上面那套 SET NX EX 和 Lua 释放讲清楚就及格了。第五题，“缓存穿透、击穿、雪崩的解决方案”。各自区分清楚了，再配合你在本地敲过的命令，就能体现真实操作经验。

需要提醒一句，这些概念在 Windows 的 Redis 上一样能验证。不要只在脑海里理解，打开 redis-cli 敲一遍SET ... NX EX，在 ARDM 里看一次不同类型 key 的可视化展示，印象会深很多。

最后再分享一个我自己的习惯：在 Windows 上反复“折腾” Redis 时，如果想快速恢复一个干净环境，最省事的办法是先停服务，然后进 Redis 目录，删除dump.rdb和 AOF 文件，再启动。Redis 就会像一个刚装好的实例一样空无一物。配合maxmemory设置，你在 Win10 下就算使劲造数据，也不用怕把开发机搞卡。这套流程我已经验证了无数遍，按文章里的顺序走一遍，你的 Windows Redis 环境会非常稳。