WSL 2下安装配置Redis完整指南：从零到主从复制与缓存治理

打开终端那一刻我一度怀疑自己是不是在 Linux 上写代码。WSL 2 这个轻量虚拟机让 Windows 下的开发体验无限接近原生 Linux而 Redis 作为后端开发绕不开的缓存中间件装在里面再顺手不过了。这个教程我边踩坑边总结把 Windows 下 WSL 安装 Redis 的完整流程、配置要点、常见坑位都整理出来按着走就能跑通后端开发、运维新手、刚接触 Linux 的同学都可以直接参考。1. 开始之前为什么偏要在 WSL 里装 Redis1.1 Windows 原生 Redis 和 WSL Redis差别到底在哪很多朋友上来第一句话就是Redis 不是有 Windows 版吗我直接下载 zip 解压就能跑为什么还要折腾 WSL这句话得分开看。Redis 官方文档写得明明白白他们不支持 Windows 平台。你能在 Git 上找到的 Windows 版本是微软团队维护的移植版版本号长期停在 3.x、5.x 这种老版本上连官方文档里都找不到它的身影。这意味着什么呢意味着你在生产环境里见过的很多新特性——Stream 数据类型、多线程 IO、Redis Cluster 的诸多优化——在 Windows 版上压根用不了。更麻烦的是Windows 版 Redis 做持久化时用的是内存映射文件稳定性、差异性和 Linux 版本有明显差距高并发场景下经常出幺蛾子。WSL 2 就完全是另一回事了。它底层跑一个真正的 Linux 内核通过 Hyper-V 虚拟化技术实现你在里面装的就是 Redis 官方推荐的 Linux 原版源码级一致不存在环境不对的问题。我个人的体会是在 WSL 里跑 Redis 跟在云服务器上跑 Redis 几乎没有区别调试时的行为、性能表现都可信不会被平台差异坑到。下表是我从实际使用角度整理的对比项目WSL 2 RedisWindows 原生版 Redis版本支持官方最新版7.x 无压力停留在老版本功能缺失内核兼容性完整 Linux 内核与生产环境一致基于 Windows API 移植有行为偏差持久化可靠性AOF/RDB 完整支持内存映射文件方案稳定性差一截学习价值配置、命令、运维技能可直接迁移到服务器只会在 Windows 上玩换环境就抓瞎安装成本一条 apt 命令或源码编译解压即用但不推荐当然也不是说 Windows 版一无是处你要是只想在本地临时起个服务跑个 demo 验证下代码逻辑直接下载压缩包确实快。但只要你打算认真把 Redis 搞明白想学点能带走的技能WSL 才是正确答案。我现在所有本地开发都在 WSL 里跑 Redis写 Go、写 Python 的服务连 localhost:6379 就能用体验非常顺滑。1.2 先确认你的 WSL 环境这一步省不了安装 Redis 之前你先得确认 WSL 环境本身是完好的。很多人卡了一下午最后发现根本不是 Redis 的问题是 WSL 没配对。第一步在 Windows 的 PowerShell 或 CMD 里敲wsl --version wsl -l -vwsl --version能看 WSL 自身版本。如果你的输出里提示版本太老、或者像 WSL needs updating your version of Windows subsystem for Linux (WSL) is too old说明你要先执行wsl --update更新到新版本。这一步卡住的人特别多因为 Windows 自带的更新源在国内经常慢到怀疑人生。我试过最快的办法是去 GitHub 上 WSL 的 Release 页面手动下载 MSI 安装包下载完双击装一下两分钟搞定完全不依赖系统更新源的下载速度。wsl -l -v是看已安装的发行版和版本号。重要的事情说三遍确认每个发行版的 STATE 是 Running、VERSION 是 2。注意WSL 1 和 WSL 2 的差距非常大WSL 1 是一个系统调用转换层很多东西不兼容WSL 2 才是完整的虚拟机内核。如果你看到 VERSION 是 1需要执行wsl --set-version Ubuntu-22.04 2把发行版转换为 WSL 2。如果你还没装任何 Linux 发行版直接来一条命令wsl --install默认会装 Ubuntu装完按要求重启。这里也有个常见坑报错 wsl/service/createinstance/createvm/hcs/error_file_not_found 这类 HCS 错误十有八九是电脑的虚拟化功能没开。你需要进 BIOS 开启 Intel VT-x 或 AMD SVM同时在 Windows 功能里勾选虚拟机平台和适用于 Linux 的 Windows 子系统然后重启。装好以后用lsb_release -a确认 Ubuntu 版本。我自己现在主力用的是 Ubuntu 22.04 LTSRedis 7.x 在上面跑得很稳。版本太老的话包管理器的源里可能没有新版 Redis但又不想编译这时候可以加 Redis 官方 PPA 或者直接升级发行版。顺带说一句如果你刚开始用 WSL 写代码推荐把 VS Code 的 WSL 插件装好配合 WSL 里的 Ubuntu 环境写代码的体验很接近 macOS 的丝滑感。字体上我推荐 Cascadia Code 或 JetBrains Mono对中文环境和连字的显示都很友好很多从 Mac 切到 Windows 的同学反馈这套组合最能找回手感。2. 安装 Redis两条路都给你摆平2.1 方案 AAPT 源安装快但版本偏保守如果你只是想快速把 Redis 用起来不想操心编译的事APT 是最省心的方案。进入 WSL 终端先更新一下软件源sudo apt update sudo apt install redis-server -y装完以后别急先看一眼版本redis-server -vUbuntu 22.04 默认源里的是 Redis 6.0.x对大部分场景来说完全够用。如果你不追求最新特性这条方案一分钟搞定依赖也被自动处理好了不用管 gcc、make 这些编译链。这里直接给一条启动命令sudo service redis-server start redis-cli ping如果返回PONG恭喜你Redis 已经在 WSL 里跑起来了。但注意这时候 Redis 还是以默认配置跑的后面第 3 章的配置项你一定要看尤其是密码和持久化不配好等于白装。2.2 方案 B源码编译安装适合需要特定版本和参数优化的情况APT 虽然快但有时候你就是要用某个特定版本。比如你在生产环境跑的是 Redis 7.2本地调试也最好用 7.2避免版本差异带来的坑。这种情况走源码编译网上查到的教程多半让你现场敲 make其实没那么玄乎。先装编译依赖sudo apt install build-essential gcc make pkg-config -y然后去 Redis 官网下载页找最新的稳定版源码包用 wget 拉下来wget https://download.redis.io/releases/redis-7.2.4.tar.gz tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 make sudo make install这里有几个点我必须提醒你。第一make过程中如果你看到关于 jemalloc 的报错比如提示 MALLOCjemalloc 相关的问题直接改用 libc 编译make MALLOClibc原因很简单Redis 默认用 jemalloc 内存分配器但某些环境缺依赖或编译链不完整时退回系统自带的 libc 分配器更省事。日常开发场景下两者差异基本感知不到。第二sudo make install会把 redis-server、redis-cli、redis-benchmark 这些二进制装到/usr/local/bin下。这样你在任何目录敲命令都能直接执行不会出现明明装好了却找不到命令的情况。第三源码编译方式不会自动帮你生成配置文件和服务脚本。你得手动拷贝一份默认配置sudo cp redis.conf /etc/redis/redis.conf后面所有配置改动都改这个文件不用去动源码目录里的原始配置。对比一下这两条路APT 方案适合求稳、快速上手源码编译适合需要特定版本、或者你想深入理解 Redis 构建过程的同学。我个人第一次用的是 APT后来为了测试 Redis 7.x 的某些特性又重新走了一遍编译流程多花十几分钟但从此对 Redis 的编译安装流程完全不虚了。2.3 安装后的第一件事验证服务真的能跑不管你用哪种方案装好都要做一轮基础验证。打开终端手动启动 Redisredis-server --daemonize yes--daemonize yes的意思是让 Redis 以守护进程方式在后台运行这样终端不会被占住窗口关了 Redis 也不受影响。启动后再敲redis-cli ping输出PONG说明服务是活的。再执行一条redis-cli info server能看到 redis_version、os、uptime_in_seconds 这些关键信息就能确认版本和运行状态了。我建议你在这里专门花两分钟玩一下redis-benchmark它是 Redis 自带的压测工具可以快速摸清当前机器的性能底子redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000-c 50代表 50 个并发连接-n 100000代表总共发送 10 万个请求。跑完会输出各类命令的 QPS 数据在 WSL 2 环境下SET/GET 一般能跑到几万甚至十几万的 QPS这个数字你在后面调优时可以拿来当基准。3. 配置 Redis这些参数不改等于白装3.1 redis.conf 到底改哪些Redis 装好只是第一步真正决定它能不能好用、能不能安全上线的是配置。默认配置是针对开发环境开箱即用设计的直接裸奔上生产会出大事。下面这几个参数我建议你装完立刻改。配置文件路径按刚才的方案在/etc/redis/redis.conf。第一个守护进程模式daemonize yes这个不解释后台运行是现代服务的基本素养。如果不开你每次都得开一个终端挂着 redis-server窗口一关服务就没了非常难受。第二个绑定地址bind 127.0.0.1保留默认就行。Redis 默认只允许本机连接这是安全底线。千万别为了图方便改成0.0.0.0除非你非常清楚风险意味着什么——Redis 没有复杂的权限体系暴露到公网等于把数据裸奔给别人。第三个设置密码requirepass 你的强密码这行默认是注释掉的一定要取消注释并设置一个足够复杂的密码。不设密码的 Redis 在内网环境里就是按需取用的数据金矿扫描器扫到就是分分钟被挖矿脚本骑脸。第四个持久化appendonly yes appendfilename appendonly.aofappendonly yes开启 AOF 持久化Redis 会把每次写操作追加到日志文件里即使断电、崩溃也能通过日志完整恢复数据。单机 Redis 一定要开不然进程一崩缓存里的数据全没了。第五个内存上限maxmemory 256mb maxmemory-policy allkeys-lrumaxmemory限制 Redis 最大占用内存maxmemory-policy是内存满了之后的淘汰策略。allkeys-lru是常用策略——最近最少使用的键先被淘汰很适合纯缓存场景。具体值根据你机器的实际内存来定WSL 2 默认会分配宿主机一半内存给虚拟机这个可以后面再慢慢调。第六个日志和持久化目录logfile /var/log/redis/redis-server.log dir /var/lib/redis这两个目录要提前建好并给 redis 用户权限不然 Redis 启动时可能因为没权限而静默失败。怎么建目录、给权限后面常见问题部分我会细说。改完配置重启 Redisredis-cli shutdown redis-server /etc/redis/redis.conf这里我强烈建议不要用redis-server裸启动每次都用redis-server /etc/redis/redis.conf指定配置文件启动才能保证你的自定义配置真的生效。我见过太多人改完配置文件不起服务回头问我为什么我配置没生效一问就是启动时没带路径。3.2 WSL 2 里的 systemd 和开机自启别踩这坑WSL 2 默认不跑 systemd这在 Ubuntu 里会带来一个反直觉的现象你执行sudo service redis-server start可能直接报错或者起来后没反应。早期 WSL 版本对 systemd 的支持很差很多人就在这里卡住。好在 WSL 的新版本已经支持在/etc/wsl.conf里开启 systemd。你可以在 WSL 终端里编辑sudo nano /etc/wsl.conf写入[boot] systemdtrue然后回到 Windows PowerShell 执行wsl --shutdown重新打开 WSL。再执行systemctl status redis-server如果能看到 active 状态说明 systemd 接管成功了。但如果你用的是旧版 WSL 或者不想折腾 systemd就老老实实用第 2 章的命令行方式启动没必要在这上面死磕。还有个更实用的自启办法编辑~/.bashrc在末尾加一行pgrep redis-server /dev/null || redis-server /etc/redis/redis.conf这样每次打开 WSL 终端都会检测 Redis 是否在运行如果没运行就自动启动。这招简单粗暴实测稳得很比配置各种 systemd 服务省心多了。当然真要在生产环境用systemd 才是正规军~/.bashrc这种方案只适合本地开发。3.3 远程访问配置怎么从 Windows 甚至局域网连过去WSL 2 默认带 localhost forwarding 功能Windows 本机访问 WSL 里的服务是直接通 127.0.0.1 的。也就是说你 WSL 里装了 Redis 监听 6379 端口在 Windows 上打开 Another Redis Desktop Manager 之类的客户端地址填 127.0.0.1、端口 6379、密码填你设置的 requirepass点连接就能进。不过有一个常见坑是 Windows 防火墙拦截。如果 WSL 里的服务改过监听地址Windows 客户端却连不上多半是防火墙对 Hyper-V 虚拟网卡的流量做了限制。排查方法Windows 防火墙入站规则里放行 6379 端口或者把专用网络的防火墙临时关掉测试一下。如果你是让局域网其他机器也来访问你机器上的 Redis光靠 localhost forwarding 就不够了。WSL 2 有自己的 NAT 网络外部机器不能直接访问虚拟机里的端口需要你在 Windows 上做一个端口转发。用管理员权限打开 PowerShellnetsh interface portproxy add v4tov4 listenport6379 listenaddress0.0.0.0 connectport6379 connectaddressWSL的IPWSL的IP可以在 WSL 里执行hostname -I查看。做完转发后局域网内其他机器访问你 Windows 机的 6379 端口流量会被转发到 WSL 里的 Redis。这个用法适合在公司内网、家里局域网环境快速暴露一个服务给同事或者手机测试用。但再次强调密码一定要设最好再配防火墙白名单不然同一局域网内被扫到就是秒级的。4. 上手实操Redis 常用数据类型的正确用法4.1 先搞清楚 Redis 到底存的是什么很多新手对 Redis 的认知只有一个快但真要让他说说 Redis 有哪些数据类型、各自适合什么场景就开始含糊了。Redis 的存储模型是 key-value但 value 不只是简单的字符串它有很丰富的数据结构。搞懂这些结构你才算真正开始会用 Redis。数据类型底层结构典型场景常用命令示例String动态字符串缓存、计数器、分布式锁SET、GET、INCR、SETNXList双向链表消息队列、时间线LPUSH、RPUSH、LPOP、BRPOPHash哈希表对象存储、购物车HSET、HGET、HGETALLSet无序集合去重、共同好友、抽奖SADD、SINTER、SPOPZSet有序集合排行榜、延时队列ZADD、ZRANGE、ZSCOREString 是用的最多的。SET一个值、GET一个值在业务里做数据缓存就靠它。配合INCR、DECR就是天然计数器比如文章阅读量、秒杀库存这些操作是原子性的在高并发下不会出现超卖问题。注意分布式锁那一章里String 的SETNX指令也是核心。List 适合做先进先出的队列。LPUSH往队头塞消息BRPOP从队尾阻塞取消息天然就是一套轻量级消息队列。很多系统没有引入 Kafka、RabbitMQ 之前就是用 Redis List 撑起了一个简单可靠的异步任务队列。Hash 的场景最贴近业务对象。比如用户的信息HSET user:1001 name 小明 age 18这样存取一个对象的多个字段比反复操作 String 效率高得多还不需要序列化整个对象。购物车、文章详情这种结构优先用 Hash。Set 是做集合运算的利器。SINTER可以快速求两个集合的交集比如我关注的人里谁关注了你一个命令搞定服务端运算量很小。抽奖活动用SPOP随机弹出一个成员公平不重复。ZSet 在 Set 基础上加了分数按分数排序排行榜功能就是为它量身定做的ZADD leaderboard 100 user1分数随时更新排名实时可见。这几个类型我建议你在 redis-cli 里亲手敲一遍不用多每个类型执行 5 到 10 条命令就够。敲完你才能体会为什么 Redis 的命令设计得像自然语言——SET、GET、LPUSH、SADD——每个动作都有明确的含义没有多余概念这是它做得好用的底层原因。4.2 在 VS Code 里连 WSL 中的 Redis开发调试的顺畅姿势如果你平时用 VS Code 写代码那么直接在 VS Code 里面操作 WSL 环境里的 Redis 是体验最好的方式。先装官方插件 Remote - WSL连上你的 Ubuntu 发行版然后在 VS Code 里打开终端直接就是 WSL 的 bashredis-cli随便敲。还可以给 VS Code 装 Redis 可视化插件比如 Redis 这个插件在侧边栏直接填 127.0.0.1:6379 和密码就能看到所有 key点击查看 value 内容。个人感觉日常调试用 redis-cli 反而更干脆看数据用可视化工具更直观。这里分享一个我自己的开发习惯在 WSL 里的项目目录下建一个Makefile或者.sh脚本把 Redis 启动、停止、清空缓存、查看慢日志这些操作写成一行命令固化下来。比如alias redis-startredis-server /etc/redis/redis.conf alias redis-stopredis-cli -a 你的密码 shutdown alias redis-flushredis-cli -a 你的密码 FLUSHALL写进~/.bashrc每次打开终端直接敲别名就行。这比每次手动补全命令参数舒服太多也减少脑子里的记忆负担。很多人觉得命令行效率低其实是你没用对工具。把重复命令打包成别名用起来快到飞起。5. 进阶玩法从单机 Redis 到主从、分布式锁和缓存治理5.1 主从复制一主一从最简搭建单机 Redis 只适合开发和测试用认真做项目就要考虑数据冗余和读写分离了。Redis 主从复制功能非常成熟配置方式也简单。在 WSL 里再复制一份配置做从库sudo cp /etc/redis/redis.conf /etc/redis/redis-slave.conf sudo nano /etc/redis/redis-slave.conf改这几个地方port 6380 replicaof 127.0.0.1 6379port改成 6380 是为了不和主库冲突replicaof指定主库的 IP 和端口。然后启动从库redis-server /etc/redis/redis-slave.conf用redis-cli -p 6380 info replication看一眼如果role:slave、master_link_status:up说明主从已经同步成功了。主库写入任何数据从库都会自动复制一份。这是最朴素的数据备份方案也是 Redis Cluster 的基石。如果你用的是 Docker现代做法会用 docker-compose 直接编排主从。这个思路也很通热词里提到的 docker 安装 redis 主从本质是同样的复制机制只是把容器编排更标准化了。WSL 里也可以装 Docker Desktop但我个人觉得单纯学 Redis 的复制机制直接起两个本地实例更直观能看清底层细节再上容器不迟。主从复制里有个细节很容易被忽略从库默认只读。也就是说客户端往从库写数据会直接报错这是 Redis 的设计避免主从数据不一致。如果你想临时在从库上做一些操作比如计算一些很大的集合需要手动把replica-read-only改为 no但测试完一定要改回来。5.2 分布式锁Redis 实现锁的经典姿势分布式锁是面试高频题也是实际项目里一定会碰到的场景。Redis 实现分布式锁的核心就一条命令SET lock_key unique_value NX EX 30000解释一下NX表示只有 key 不存在时才设置成功——这是加锁语义EX 30000表示锁的过期时间为 30 秒——这是自动释放防止持有锁的进程崩了导致死锁。unique_value是客户端自己生成的唯一标识释放锁的时候要校验这个值是不是自己的防止误删了别人后来抢到的锁。释放锁用 Lua 脚本保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end为什么用 Lua因为判断是当前线程的锁再删除这两步在普通指令下不是原子的并发高时可能出现线程 A 执行完业务还没删锁锁过期了线程 B 拿到了锁然后 A 把 B 的锁删了锁就彻底失效。Lua 脚本把比较和删除打包成一个原子操作这个问题就迎刃而解。这里多说一句网上有很多文章把 Redisson、RedLock 说得神乎其神但 RedLock 在学术界和工程界都有不少争议在大多数业务场景下用上面这种单节点 Redis 加锁方式配合合理的业务容错已经能满足需求。如果确实需要更高的强一致性建议先把业务逻辑设计拆解清楚而不是一上来就把复杂度拉满。从 WSL 里演示一遍会更直观。开三个终端模拟三个客户端同时加锁redis-cli SET order:1 lock_a NX EX 30 redis-cli SET order:1 lock_b NX EX 30第一个终端会返回 OK第二个返回 nil。拿到锁的模拟执行业务最终执行 Lua 释放锁没拿到的就重试或直接返回失败。这个流程走一遍你对分布式锁的理解就通透了。5.3 缓存治理穿透、击穿、雪崩怎么破公司里说到Redis 缓存治理大概率就是在谈这三个问题穿透、击穿、雪崩。我给你用人话讲明白。缓存穿透是指查询一个根本不存在的数据Redis 里没有数据库里也没有每次请求都打到数据库。攻击者就是用这个逻辑制造大量无效查询把你的数据库打挂。解法一是把空结果也缓存起来设置短过期时间比如 5 分钟解法二是用布隆过滤器在查询前先判断 key 是否存在不存在直接短路返回。缓存击穿是指某个热点 key 在过期瞬间大量请求同时打到数据库。这跟穿透不一样击穿的目标是存在但刚好过期的 key。解法一是互斥锁——只让一个线程去数据库回源其他线程等待结果解法二是把热点 key 的逻辑过期时间延长并且做主动续期。缓存雪崩是指大量 key 在同一时间段集体过期导致数据库流量瞬间爆炸。解法也直接过期时间不要设成一样的加个随机值让过期时间均匀分散或者用多级缓存本地缓存 Redis 双保险再或者对核心数据做永不失效 后台异步更新。这三个问题的核心是你能不能理解缓存和数据库之间那层微妙的依赖关系。缓存是挡在数据库前面的盾盾如果被绕过了、被集中打穿了数据库就裸奔了。理解了这一层你再去设计方案就会很自然——布隆过滤器、互斥锁、随机过期时间都是在这条思路上补洞。6. 问题排查Windows 下用 WSL 装 Redis 最容易踩的坑6.1 常见错误速查表以下问题都是我实际遇到的或者身边同事问过我多次的直接从现象到解法列出来问题现象可能原因解决办法wsl --update 下载很慢默认使用微软官方更新通道国内网络不稳定去 GitHub WSL Release 页手动下载 MSI 安装包安装提示 WSL needs updating... version is too oldWSL 版本过旧缺少新特性执行 wsl --update或手动安装最新 WSL报错 error_file_not_found / HCS 错误BIOS 虚拟化未开启或 Windows 功能里虚拟机平台没勾选进 BIOS 开启 VT-x/SVM启用Windows 虚拟机监控程序平台后重启redis-server 启动后找不到 PID 或秒退配置文件路径不对或日志目录无权限使用 redis-server /etc/redis/redis.conf 启动mkdir -p /var/log/redis /var/lib/redis chown redis:redis 目录Windows 上 Redis Desktop Manager 连不上 WSL 里的 RedisRedis 只 bind 了 127.0.0.1正常但 WSL 端口转发有问题本地连接用 127.0.0.1 访问外部机器连接用 netsh portproxy 做转发WSL 里删除文件后磁盘空间没释放WSL 2 使用 ext4 虚拟磁盘不会自动收缩空间wsl --shutdown 后用 diskpart 或 DiskGenius 压缩 vhdx 文件redis-cli 执行命令报 NOAUTH设置了 requirepass但没输入密码redis-cli -a 你的密码或在交互模式里执行 AUTH 你的密码make 编译 Redis 报 jemalloc 相关错误某些环境下 jemalloc 编译链有问题make MALLOClibc 重新编译Windows 防火墙拦截局域网连不上 Redis 6379Windows Defender 防火墙默认拦住入站连接防火墙入站规则放行 6379或者对指定 IP 加白名单6.2 几条实际踩坑后的心得先说 WSL 磁盘空间的问题这个和 Redis 没直接关系但开发环境天天会遇到。WSL 2 的程序装在 ext4 虚拟磁盘里Windows 上对应一个 vhdx 文件这玩意儿的特性是只增不减。你在 WSL 里删了几十个 G 的文件Windows 上的 vhdx 文件大小一点都不变因为空间已经被预分配到虚拟磁盘里了。解决方法是关掉 WSL 后用 diskpart 收缩虚拟磁盘网上教程一抓一大把。我自己现在的习惯是定期清理 WSL 里的包缓存和临时文件防患于未然。再说我踩得最深的一个坑WSL 里 Redis 配置文件改完以后用service redis-server restart重启结果配置没生效。排查了半天发现 service 方式启动读的是/etc/redis/redis.conf没错但service脚本在某些 WSL 版本里对 systemd 依赖有问题导致启动的是默认配置。从那以后我只用两条命令redis-cli shutdown停掉服务redis-server /etc/redis/redis.conf手动指定配置启动。简单可靠从不背锅。还有一个很容易被忽略的是 Redis 日志。服务起不来了第一件事就去翻/var/log/redis/redis-server.log。日志记录了 Redis 启动过程的每一个关键步骤和报错原因比你在终端里瞎猜高效得多。配置完目录权限之后我习惯用tail -f /var/log/redis/redis-server.log挂一个终端看启动过程有没有 WARNING 或者 ERROR有就直接对症下药。最后分享一个小技巧。Redis 官方提供的redis-cli --latency和redis-cli --slowlog两个命令能帮你快速定位性能瓶颈。--latency测试客户端到 Redis 的网络延迟SLOWLOG查看慢命令记录。我排查过几次线上诡异延迟问题最后都是靠SLOWLOG揪出那些不该存在的KEYS *操作——这个命令在生产环境千万不要用它会全库扫描导致阻塞应该用SCAN代替。