先说个题外话我几乎每天都能在群里看到有人问 Redis 的问题问得最多的是安装失败、连不上、超时、缓存穿透以及分布式锁到底怎么写才对。这些问题说大不大但每个都够让人折腾一两个小时的。我自己从最开始在 Windows 上装 Redis 4.0.8 被坑得死去活来到后来负责的线上服务用 Redis 7.0 做缓存和分布式锁中间踩过不少坑。这篇就把这些“常见问题”集中梳理一遍覆盖安装配置、数据类型、缓存治理、分布式锁、持久化、以及高频报错排查尽量让不同阶段的读者都能直接拿走用。如果你刚接触 Redis可以照着安装和配置部分操作如果已经用了一段时间但总是遇到诡异问题直接从缓存治理和报错排查部分看起如果你是准备面试或者要自己设计缓存方案那数据类型和分布式锁部分应该对你有帮助。我尽量把“为什么会这样”也讲清楚因为只告诉你怎么改不告诉你为什么改换个场景你还是会懵。1. 版本选不对后面全是坑安装前后必须想清楚的几件事1.1 先明确你要用哪个版本别盲目下载最新版很多初学者打开官网直接点 Download把 Redis 7.2 甚至 latest 版本拉到生产环境结果发现 CentOS 7 的 glibc 版本太老编译直接报错。这不是 Redis 的问题是版本和系统兼容性的问题。我建议分场景选版本生产环境偏保守一般选 6.2.x 或 7.0.x。6.2 是长期维护版本资料多、坑少7.0 引入了函数、多 AOF 文件等能力稳定性在 7.0.x 后期版本已经很不错。新项目追求新特性选 7.2.x但要注意客户端驱动是否支持尤其是 Spring Boot 项目里 Lettuce 和 Redisson 的版本。只是本地学习练习无所谓最新版即可跑不坏的。还有一个很现实的问题网上大量教程还在用 3.x、4.x 的命令习惯比如config set appendonly yes、SLAVEOF这些新版本里部分命令已经改名REPLICAOF旧语法可能提示错误。如果你照着老教程操作报错先查一下 Redis 版本和命令兼容性别急着怀疑环境有问题。1.2 Windows 安装MSI、免安装、WSL 三种方式怎么选Windows 下装 Redis 有三个常用途径各有各的坑。最稳妥、我实际用下来体验最好的是 WSLWindows Subsystem for Linux里装官方 Linux 版。原因很简单Windows 上的 Redis 基本都是第三方移植版官方不支持 Windows。你从tporadowski/redis这类项目下载的 5.0.14.1 版本用来学习没问题但跑生产或研究哨兵、集群这类功能行为和 Linux 版会有差异遇到问题网上能参考的方案也少。如果你只是本地调试、想快速跑起来用解压免安装版最省事。下载 zip 压缩包解压到目录后命令行里执行redis-server.exe redis.windows.conf常见报错是双击 redis-server.exe 直接闪退或者提示Creating Server TCP listening socket *:6379: bind: No error这种大概率是 6379 端口被占用或者配置文件路径没写对。排查顺序是先看端口占用再确认配置文件是否与 exe 在同一目录。第三种 MSI 安装包方式最省心安装时会自动注册 Windows 服务开机自启适合不想折腾的初学者。但切记MSI 安装后默认没有密码6379 端口会对局域网暴露如果你在公司网络环境记得安装后立刻改配置。1.3 macOS 安装Homebrew 和源码编译两种路线macOS 用户优先用 Homebrewbrew install redis brew services start redis装的版本一般比较新配置文件在/opt/homebrew/etc/redis.confApple Silicon或/usr/local/etc/redis.confIntel。用brew services启动的好处是自动后台运行开机自启适合本地开发。如果遇到redis-cli ping返回Could not connect to Redis at 127.0.0.1:6379: Connection refused大概率是服务没起来先执行redis-cli ping看看再brew services list确认状态。还有一个 macOS 特有的问题如果之前用redis-server前台启动过端口被占用新进程起不来报错信息是这个端口已在监听直接杀掉旧进程就好。1.4 Docker 安装镜像名称一个字母都不能错用 Docker 跑 Redis 是目前我推荐最多的方式因为它隔离干净删掉重建成本低。但坑在镜像标签上。初学者最容易犯的错误是直接执行docker search redis然后选一个 star 数最多的镜像拉取。Docker Hub 上存在大量非官方镜像有些内置了奇怪的配置甚至恶意脚本。正确做法是只认官方镜像redis拉取时明确指定版本标签docker pull redis:7.0.15 docker run -d --name redis-server -p 6379:6379 redis:7.0.15 --requirepass mypassword这条命令里--requirepass mypassword是作为容器启动参数传给 redis-server 的不是 compose 文件里的配置项。如果你想灌入自定义配置文件需要把宿主机配置文件挂载进去例如docker run -d --name redis-server \ -p 6379:6379 \ -v /my/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7.0.15 redis-server /usr/local/etc/redis/redis.conf很多人在这一步懵了镜像名后面的redis-server /usr/local/etc/redis/redis.conf其实是覆盖容器默认启动命令官方镜像默认会把redis-server作为 CMD如果你只挂载配置但不改启动命令配置文件不会生效。另外搜索镜像时偶尔会看到类似docker search redis request returned 500 internal server error的报错这通常是 Docker Desktop 的引擎没完全启动好或者访问 Docker Hub 网络不稳定重启 Docker Desktop 基本能解决跟 Redis 本身没关系。2. 配置文件高频翻车现场连不上、密码不生效、内存被打爆2.1 protected-mode 和 bind 配置是连接失败的罪魁祸首我见过最多的场景是Redis 在云服务器上装好了本地用可视化工具死活连不上redis-cli在服务器本机却一切正常。如果你也是这种情况先检查两个配置项。第一是protected-mode。Redis 默认是 yes这个模式下如果bind没有显式指定可以访问的地址同时没有设置密码Redis 只接受本机回环地址127.0.0.1的连接。外部访问会被拒绝。要允许外部连接要么设密码要么显式配置bind。第二个是bind。默认配置里是bind 127.0.0.1 -::1只监听本机。我在实际项目中见过有人图省事直接改成bind 0.0.0.0结果 Redis 暴露到公网还被扫描器拉到挖矿脚本的非常危险。这里给你一个相对安全的折中方案bind 0.0.0.0 protected-mode yes requirepass 你的强密码把监听地址放开到所有网卡但用 protected-mode 兜底、密码挡在前面。如果服务器有安全组/防火墙一定只放行来源 IP不要对全网开放 6379。2.2 requirepass 设置后好几个地方都得跟着改密码设置看似简单但它影响的点是分散的。命令行连接要加-a可视化客户端要填密码Spring Boot 配置文件要写 password哨兵模式里还要单独配置 sentinel 的 auth-pass。Windows 玩家在配置文件里找到# requirepass foobared去掉注释改成自己的密码然后重启服务。如果配置改了但不生效检查一下启动时是否带了配置文件路径。很多人直接双击 redis-server.exe启动时是默认配置根本没加载你改的那个 conf 文件所以密码当然不生效。正确做法是用命令redis-server.exe redis.windows.conf启动或者把配置文件路径写进服务启动参数里。一个容易混淆的坑config set requirepass xxx确实能临时改密码但重启后失效。如果你想持久化必须config rewrite。可这个命令不是所有场景都好使在 Docker 容器里经常因为权限问题写入失败所以我建议密码这类关键配置直接改配置文件别依赖运行期命令。2.3 maxmemory 不设上限线上 Redis 迟早 OOMRedis 作为缓存使用时最容易被忽略的是maxmemory。默认值是 0表示不限制意思是 Redis 会一直占用内存直到操作系统撑不住触发 OOM Killer 直接杀掉 Redis 进程。这种情况我处理过不止一次服务器内存监控告警连上去发现 Redis 占了几个 G应用层的缓存 key 一直往里写但从来没考虑过淘汰。生产环境一定要设置上限并且配置淘汰策略。我的建议maxmemory 2gb maxmemory-policy allkeys-lruallkeys-lru是按最近最少使用淘汰所有 key如果你有一些 key 绝不能丢比如临时锁、计数类业务数据需要使用volatile-lru它只淘汰设置了过期时间的 key。noeviction是默认策略内存满了直接报OOM command not allowed when used memory maxmemory很多新开发第一次遇到这个报错就是这个原因。关于内存估算INFO memory命令里used_memory_human可以看实时占用mem_fragmentation_ratio如果大于 1.5 说明内存碎片严重考虑重启或调整内存分配策略。2.4 慢查询日志和运行日志是排查问题的第一入口连接超时、命令卡顿这些问题第一件事不是猜而是看慢查询日志。Redis 慢查询日志通过两个参数控制slowlog-log-slower-than 10000 slowlog-max-len 12810000单位是微秒即超过 10ms 的命令会被记录。线上建议调低到 5000 甚至 2000因为一次 O(n) 操作的 keys 命令可能跑几百毫秒不记录根本发现不了。查看方式SLOWLOG GET 50 SLOWLOG LEN运行日志方面配置文件里的loglevel notice级别够用排障时可以临时调成debug但生产环境不建议开日志量太大磁盘会很快被写满。还要注意日志文件大小建议配合 logrotate 做日志轮转不然/var/log/redis会把磁盘占满这种故障我见过太多次了。3. Redis 数据类型不是背命令就行这些坑才是真正的问题3.1 String 不只是缓存计数器才是效率杀手锏面试被问或者日常使用时String 的常见场景是缓存字符串但它的原子自增INCR、DECR才是很多高并发系统的核心依赖。比如生成自增 ID、计数、限流统计。用INCREXPIRE可以实现一个最简单的滑动窗口限流起点。String 的坑主要在序列化和内存占用上。我在一个项目里发现同样的内容用 JDK 原生序列化存进去的 key 带了一长串类型前缀value 是二进制流不仅肉眼无法识别内存占用也比 JSON 大了好几倍。后来统一换成 JSON 序列化内存立刻降了 40%。如果你用 Spring Data Redis序列化器一定要显式配置别用默认的 JdkSerializationRedisSerializer。3.2 List 到底该当队列用还是栈用方向别搞反List 常用的两种操作组合是 LPUSH RPOP队列先进先出和 LPUSH LPOP栈后进先出。逻辑不难但实际项目里很容易因为业务模型理解错把队列当栈用导致消息处理顺序完全反过来。再一个高频坑LRANGE key 0 -1取全量。如果 list 里面有几十万个消息这条命令会一次性把数据拉出来Redis 是单线程大 key 复杂度 O(n) 的操作直接会让整个实例卡顿。我见过线上 Redis 因为一个大 list 执行 LRANGE导致同一实例上其他业务请求全部超时。处理办法是如果需要批量消费用LRANGE配合LTRIM分段处理或者把大 key 拆成多个小 key 按时间分片。3.3 Hash 存对象省内存但没有字段级过期Hash 适合存对象的属性集合比如用户信息、商品信息好处是修改单个字段时不需要整个 value 序列化反序列化HINCRBY做字段级计数也很方便。而且 Hash 在字段少的时候内存编码更紧凑比存 JSON String 省很多内存。但注意Hash 没有字段级过期时间只有整个 key 的过期时间。我经常被问到“怎么给 Hash 里某个字段设 5 分钟过期”答案是Redis 本身不支持要么拆 key每个字段一个 key要么在业务层记录每个字段的过期时间定期扫描清理。没有第三种优雅办法别再想歪招。还有一个细节HGETALL对于大字段很多的 Hash 同样是大 key 操作线上环境要慎用特别是从库读取的高频场景可能造成主从复制延迟。3.4 Set 不只是去重SINTER 让你省掉一次循环Set 最基础的是去重和随机抽取比如抽奖系统用SPOP。但很多人忽略了 Set 的集合运算能力SINTER交集、SUNION并集、SDIFF差集在权限系统里做多个角色取权限集合、社交系统里找共同好友一条命令解决问题比在代码里循环查询高效得多。Set 的坑在无序性和内存。Srandmember 抽取是随机的不保证每次都不一样如果需要抽完就移除要用SPOP。另外 Set 底层如果用 hashtable 编码一个百万成员的 Set 占用的内存不低必要时考虑用 Bitmap 代替纯成员集合但复杂度会上升小项目不值得。3.5 ZSet 用在排行榜和延迟队列分数精度不可忽略ZSet 的典型场景是排行榜ZADD写入分数ZREVRANGE取前三名。这里有个看起来不起眼但实际影响很大的点分数是 double 类型。涉及金额、交易量这种场景浮点误差会导致排行顺序和预期不一致。我通常在业务层把分数换算成整数比如金额乘以 100 存成分或者存时间戳作为排序分数。ZSet 另一个好用但少有人提的场景是延迟队列把任务执行时间作为 score不断用ZRANGEBYSCORE key -inf now LIMIT 0 10拉取到期任务处理完 ZREM 移除。这个方案比定时扫表高效很多但要注意单个 ZSet 过大的问题以及消费者挂了以后积压任务瞬间拉取的压力。3.6 WRONGTYPE 报错原因永远是数据类型不匹配WRONGTYPE Operation against a key holding the wrong kind of value这个报错翻译过来就是这个 key 已经存在而且类型和你操作的命令不匹配。最常见的场景是代码里先存了一个 String后来版本迭代另一个接口拿同一个 key 做 List 操作直接报错。排查方法很简单TYPE key看类型或者DUMP序列化看内容。要提醒的是这个报错在 Redis 集群模式下更隐蔽因为不同 key 可能落在不同槽位同一个 key 在不同业务模块被复用的情况更难查。建议团队内部约定 key 命名规范比如module:object:field的格式不同模块不要共用一个 key。4. 缓存治理穿透、击穿、雪崩每一种都有对应的解法4.1 缓存穿透空值缓存与布隆过滤器的取舍缓存穿透是指查询一个根本不存在的数据请求绕过缓存直接打数据库如果请求量大数据库会被拖垮。我接手过的一个项目凌晨被脚本灌了几十万个不存在的用户 ID数据库连接瞬间打满。两种主流方案空值缓存是最简单的查询数据库返回 null 时也把这个 key 缓存起来设置短期过期时间比如 3 到 5 分钟。注意设置过期时间不然这些空 key 越积越多白白占内存。而且空值缓存的 TTL 不能太长否则业务上真的写入这个 key 后用户要等缓存过期才能看到新数据。布隆过滤器是另一个方案把所有可能存在的数据 ID 提前放到 Bloom Filter 里请求过来先判断 ID 是否可能存在不存在直接返回。这个方案的优点是内存占用极小百万级数据也只占几 MB缺点是存在误判率宁可错杀一百也不放过一个而且实现成本高需要引入 Redisson 的 RBloomFilter 或自己实现。我的经验是小规模服务空值缓存完全够用只有数据库压力已经很明显、查库量大的时候再上布隆过滤器。4.2 缓存击穿热点 key 失效瞬间的并发冲击缓存击穿是某个热点 key 在过期瞬间大量请求同时打到数据库。典型场景是秒杀商品详情页的缓存 10 分钟失效瞬间数万请求涌进来。两种主流方案互斥锁方案缓存未命中时先尝试获取分布式锁只有拿到锁的线程去查数据库并回写缓存其他线程阻塞等待后重新读取缓存。我建议用 Redisson 的tryLock而不是自己去 SETNX因为 Redisson 处理了续期和释放问题能少写很多 bug 代码。这个方案的缺点是会阻塞请求极端情况下可能拖慢响应。逻辑过期方案缓存里不设置物理过期时间而是保存一个逻辑过期时间字段。查询时判断逻辑时间是否过期如果过期则尝试获取锁拿到锁的线程异步重建缓存旧数据继续返回给用户。这种方案不会阻塞请求能保证高并发下的响应速度但业务短暂读到旧数据。适合允许最终一致性的读多写少场景。4.3 缓存雪崩批量过期和宕机时的整体防线雪崩最典型的原因是同一时间大量 key 同时过期或者 Redis 实例整体宕机。前者容易预防后者需要架构设计。批量过期问题的解法很朴素设置过期时间时加随机值。比如基础 TTL 是 1 小时实际过期时间设为 1 小时加上 0 到 300 秒的随机偏移。这样同一时刻过期的 key 数量大幅减少。我一般会在封装缓存工具类时就把随机偏移写进去不让业务方单独设置。Redis 节点宕机这个维度要有连接降级方案本地加一层进程内缓存兜底、数据库限流熔断、多级缓存架构。记住一个原则Redis 挂了不能让数据库跟着挂。建议压测时做一次故障演练主动杀掉 Redis 看业务表现很多问题到故障那一刻才暴露就晚了。4.4 缓存一致性先更新数据库还是先删缓存别再争论了缓存和数据库的一致性问题是缓存系统里最烦人的问题。先更新数据库再删缓存是目前相对更安全的方案。为什么如果先删缓存再更新数据库在删缓存之后、更新数据库之前有请求读缓存未命中就会把旧数据写进缓存导致缓存里长时间是脏数据。而先更新数据库再删缓存中间窗口极小只有在更新数据库成功、删除缓存失败的情况下才会不一致。为了处理这个窗口期可以配合延迟双删更新数据库后等待几百毫秒再删一次缓存。但是先更新数据库再删缓存在极端场景下还是有瑕疵事务还没提交另一个线程已经读了旧数据并回写缓存然后事务提交缓存里还是旧数据。延迟双删 消息队列最终一致性补偿是生产级的成熟套路。个人经验是别追求强一致缓存系统能接受最终一致只要把过期时间设置成业务能容忍的窗口大部分问题自然消失。5. Redis 分布式锁SETNX 只是起点续期和误删才是核心5.1 正确写法SET key value EX seconds NX而不是先 SETNX 再 EXPIRE网上很多老教程教你SETNX lock 1 EXPIRE lock 30这是很危险的两条命令。如果 SETNX 成功但 EXPIRE 没执行比如进程崩溃、网络抖动锁就没有过期时间其他线程永远拿不到锁。正确做法是用一条原子命令SET lock 唯一标识 EX 30 NXRedis 2.6.12 之后这个组合就一直可用别再写两步操作了。为什么 value 要唯一标识因为解锁时要用 Lua 脚本校验if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end如果不校验直接 DEL可能出现 A 线程还没执行完、锁超时被自动释放B 线程拿到锁A 线程执行完直接 DEL 把 B 的锁删了。这个误删问题我见过真实的线上事故排查起来还特别难因为锁删掉的那一刻没有日志。5.2 锁超时导致业务并发执行怎么兜底即使设置了合理的过期时间锁还是可能因为业务执行时间过长而到期。这时候两个线程同时执行业务锁就形同虚设。解决方案是看门狗自动续期机制。Redisson 里提供了现成的 watchdog默认锁持有时间是 30 秒每 10 秒检查一次如果业务还在执行就自动续期。用起来很简单RLock lock redissonClient.getLock(myLock); lock.lock(10, TimeUnit.SECONDS); try { // 业务逻辑 } finally { lock.unlock(); }注意如果传入 leaseTime租约时间Redisson 不会启用 watchdog 续期。我见过有人传了 5 秒的 leaseTime业务跑 10 秒锁在第 5 秒就没了并发问题照样发生。正确做法是不传 leaseTime让 watchdog 帮你续期。5.3 主从切换时锁会丢Redlock 是否必要取决于你的场景Redis 主从架构下有一个天生的问题主节点拿到锁但主节点还没来得及同步到从节点就宕机了从节点升级为主节点后锁就丢了。这个问题分布式锁领域里被称为“脑裂下的锁失效”。Redis 官方给出的答案是 Redlock向多个独立节点依次加锁超过半数成功才算加锁成功。但 Redlock 在业界争议很大Martin Kleppmann 专门写过文章质疑它的安全性和性能。我的实际经验是如果你的场景是防止重复下单、防止重复发放优惠券能接受极小概率的并发重复那么普通 SET EX NX 锁 业务幂等校验就够了如果场景是金融级强一致那不建议用 Redis 做分布式锁应该考虑数据库行锁或 ZooKeeper。这个取舍要提前想清楚别指望一个工具解决所有问题。6. 持久化、主从哨兵、集群从单机到高可用要避开的坑6.1 RDB 和 AOF一个管备份一个管恢复速度持久化方面我常被新手问RDB 和 AOF 到底选哪个正确答案是看你丢数据的容忍度。RDB 是快照默认 60 秒内如果有 10000 次写操作就会触发一次快照生成。优点是恢复速度快、文件紧凑适合备份缺点是两次快照之间的数据会丢。如果 Redis 进程直接宕机最近一次快照之后写入的数据都没了。AOF 是追加写日志默认appendfsync everysec每秒 fsync 一次最多丢 1 秒数据。默认开启的 aof-use-rdb-preamble 会先写 RDB 格式再追加增量兼顾了恢复速度和数据安全。我的建议很简单生产环境同时开 RDB 和 AOFRDB 负责定期备份和快速恢复AOF 负责兜底秒级数据安全。同时开启不会有什么性能问题前提是磁盘 IO 正常。如果 Redis 写吞吐特别高注意 AOF 重写可能造成的磁盘压力auto-aof-rewrite-percentage 100这种参数要根据写入量调整。6.2 主从复制不是高可用哨兵才是很多人以为配了主从复制就高可用了这是个大误区。主从复制只解决读压力和数据冗余主节点宕机后从节点不会自动变成主节点应用还是连接已宕机的地址照样不可用。真正的高可用要引入哨兵Sentinel。哨兵负责监控主节点状态发现主节点故障时自动执行故障转移把一个从节点提升为主节点并通过发布订阅通知客户端更新主节点地址。搭建哨兵时有几个容易出错的地方sentinel 配置文件里sentinel monitor mymaster 127.0.0.1 6379 2最后的数字 2 表示至少两个哨兵同意主节点下线才触发故障转移而不是哨兵数量。如果哨兵只有 1 个实例这个数字就得是 1否则永远无法触发故障转移。另外主节点设置了 requirepass所有从节点和哨兵都要配对应的密码否则复制连接和哨兵探活都会失败日志里一堆MASTER auth failed。6.3 Cluster 集群模式下多 key 操作和槽位迁移才是重点Redis Cluster 用哈希槽分布式存储数据总槽位 16384 个每个 key 通过 CRC16 算法计算归属的槽位。这让集群可以水平扩展但有几个业务上必须要注意的限制第一多 key 操作如 MGET、MSET、事务、Lua 脚本只有在 keys 都落在同一个槽位时才支持否则报CROSSSLOT Keys in request dont hash to the same slot。解决办法是用哈希标签hash tag例如{user123}:profile、{user123}:orders让同一个用户相关的 key 都hash 到同一个槽位。第二集群模式下KEYS命令不可用因为数据分散在多个节点上。要用SCAN命令遍历或者借助redis-cli --cluster的子命令操作集群。第三槽位迁移期间来自客户端的访问可能间歇性报MOVED或ASK重定向。正常客户端驱动都会自动处理但如果是自己封装的连接池要小心处理重定向逻辑否则迁移时会出现请求失败。如果你准备在 K8s 里跑 Redis 集群难度比裸机更大因为节点的网络标识变化会影响集群状态。用 StatefulSet 加 headless Service 稳定 DNS 名称是基本操作Operator 方案也有不少例如 spotahome/redis-operator但无论哪个方案都要先演练节点重启后的集群恢复。6.4 可视化工具选择装机率最高的三款怎么挑关于可视化客户端我从很多读者的问题里能感受到工具选型也是在走弯路。最常见的三款Redis Desktop ManagerRDM老牌工具稳定但新版已经商业化免费版功能受限。如果你用的是旧版本 2020 左右的免费版连 Redis 6 的 ACL 用户时会遇到兼容问题连不上的话别怀疑配置先考虑版本。Another Redis Desktop Manager免费开源连接功能完全够用支持哨兵和集群模式我目前个人主力使用这款。它的数据浏览、命令行执行、慢查询展示都还过得去遇到 Git 下载慢的问题可以找国内镜像。Redis InsightRedis 官方出品界面新、功能强支持图形化分析内存、跟踪慢查询、查看 pub/sub 消息。但相比前两款资源占用高一些轻量环境不推荐常驻建议排查问题时临时开。连接时报错要分清是密码问题还是网络问题。工具里配置密码后如果仍然NOAUTH Authentication required先看一下连接URL里密码是否存在特殊字符比如、#这类需要 URL 编码。如果提示Connection refused大概率是 Redis 的 bind 或防火墙没有放开。7. 高频报错排查实录遇到这些错照着这个顺序查7.1 Redis command timed out 是 Lettuce 超时连接池是头号嫌疑Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException这个报错在 Spring Boot 项目里出现频率极高。表面意思是命令执行超过客户端配置的超时时间但背后原因通常是这几类第一Lettuce 连接池默认配置不满足高并发需求。Spring Boot 2.x 默认 Lettuce 的最大连接数和最大等待时间都比较保守高并发时线程在获取连接上排队队列超时就会抛异常。解决方向是显式配置连接池参数spring: data: redis: timeout: 3000ms lettuce: pool: max-active: 32 max-idle: 16 min-idle: 4 max-wait: 1500ms注意timeout设置的是命令执行超时不是连接池获取超时两个参数要分开理解。第二Redis 服务端慢查询拖累了所有请求。如果你发现报错集中在某个时间段马上去看SLOWLOG GET如果是大批量KEYS、HGETALL大 key 操作先把慢命令停掉。第三单实例吞吐到瓶颈。如果是 CPU 长期高占用连接数打满考虑拆分实例或引入集群而不是继续调大连接池调大连接池只会让 Redis 端更快崩溃。7.2 Connection refused按网络可见性依次排查连接拒绝是所有 Redis 新人躲不开的问题。排查顺序建议Redis 进程是否存活本机redis-cli ping看是否有 PONG。端口是否被监听ss -lntp或netstat -antp看 6379 是否在监听。bind 地址是否包含客户端网段Redis 配置文件bind 127.0.0.1只允许本机访问。protected-mode如果 bind 配置了公网 IP 但没设密码Redis 会拒绝连接。防火墙和安全组服务器防火墙、云安全组是否放行了 6379。这一步最容易被忽略我在腾讯云和阿里云上都遇到过安全组没配导致外部连不上。还有一个 Windows 特有的问题Windows 防火墙偶尔自动拦截 redis-server 的入站连接局域网其他机器连不上本机却正常。直接在防火墙规则里放行 6379 即可。7.3 OOM command not allowed 不是物理内存耗尽是 maxmemory 用完了这个报错常让新手误以为服务器没内存了其实意思是 Redis 达到了maxmemory限制且当前淘汰策略不允许写入。如果设了noeviction内存满后所有写操作都会被拒绝。处理时先看INFO memory确认是否真的到上限再执行CONFIG GET maxmemory-policy看淘汰策略。如果业务可以接受部分冷数据被淘汰改成allkeys-lru是最快的恢复方式。如果 Redis 里存的数据有严格语义不能随便淘汰那就只能扩容或拆 key。我之前在一个项目中遇到这个报错便是因为缓存 key 在不同业务中使用同一个过期时间导致同时堆积内存提前打满最后统一加随机 TTL 才解决。7.4 MISCONF 持久化失败磁盘满或权限问题MISCONF Redis is configured to save RDB snapshots, but it is currently unable to persist on disk是另一个容易误判的报错很多人以为 Redis 挂了其实只是后台 RDB 快照写入失败。常见原因磁盘空间满、Redis 运行用户对 dump.rdb 所在目录无写权限、AOF 重写时磁盘瞬时压力过大。排查思路是先df -h看磁盘再确认文件所有者最后看 Redis 日志中具体写入失败原因。临时恢复可以用CONFIG SET stop-writes-on-bgsave-error no让 Redis 继续接受写请求但这只是止血磁盘问题不解决数据安全没有保证。7.5 连接数告警和“max number of clients reached”怎么办maxclients默认 10000看起来很高但如果有大量连接不正常关闭客户端连接池泄漏、没有正确归还连接很容易打满。上面提到 Lettuce timeout 时很多人忽略了一个本质原因连接泄漏。排查方式是在 Redis 上执行CLIENT LIST观察连接来源和空闲状态同时宿主机的ss -s可以看 ESTABLISHED 状态数量变化。最终根治的方法可能是升级到 Redis 6.x 并引入客户端空闲连接回收机制。8. 一些我的个人经验与扩展建议回到文章开头的那个场景群里总有人问 Redis 问题其实很多问题背后的原因是没建立起排查思路。我个人在项目里逐渐固定下来的几个习惯分享出来供参考第一统一封装 Redis 操作工具类不要直接在业务代码里到处 new RedisTemplate 或者 Jedis。封装层里集中处理序列化、key 前缀、缓存穿透和击穿的兜底逻辑团队协作时能少踩很多坑。序列化问题尤其明显Spring Data Redis 中 RedisTemplate 默认 JDK 序列化value 在 Redis Desktop Manager 里是一团乱码排查数据问题时非常痛苦。第二Redis 不能只当作缓存用它的数据结构能力能为业务省很多时间。Set 做去重、ZSet 做排名、Stream 做轻量消息队列这些能力比额外引入中间件成本低得多。但也要克制不要在 Redis 里存过于复杂的业务逻辑读写放大和内存占用会让运维很难受。第三先监控后优化。上线 Redis 前至少把INFO memory、INFO stats、SLOWLOG采集到监控面板很多问题是缓慢恶化的等用户报障时已经晚了。我处理过一次事故缓存命中率从 95% 缓慢降到 30%持续了三周才被发现原因是代码里一个缓存 key 拼错了字段等于所有读取都在直接查数据库。没有监控根本不可能定位这种问题。最后再给大家一个实操小技巧排查 Redis 故障不要只盯着 Redis 本身还要看客户端版本、连接池配置、网络链路。很多“Redis 超时”其实不是 Redis 慢而是跨机房网络延迟、TCP 重传造成的。你可以在客户端抓包看一下命令耗时分布或者用redis-cli --latency -h 目标IP测量真实的命令往返延迟这一招在大型网络环境中排查超时问题非常管用。