带过不少实习生也面试过不少应届生Redis 问一圈基本就能摸清一个人的工程底子。问数据类型能背出五种但一问到序列化乱码、缓存击穿、分布式锁续期十个人里有八个开始含糊。这篇东西不是把 Redis 官方文档再抄一遍而是站在 Java 后端工程的角度把实习生入职后真正会碰到、线上容易踩坑的那些知识点串一遍数据类型怎么选、序列化为什么乱码、连接超时怎么排查、分布式锁怎么落地、缓存三大问题和一致性怎么处理。全程用项目里真实发生的场景说话看完直接能用到你的 demo 和第一个线上需求里。1. 先想明白Redis 在 Java 工程里到底扮演什么角色很多实习生上来就敲命令SET 一个值然后 GET 回来觉得自己会 Redis 了。但工程里 Redis 从来不孤立存在它是因为解决某个真实问题才被引入的。先把这个为什么想清楚后面所有知识点才有落点。1.1 为什么是 Redis 而不是本地 Map你写单机 demo 的时候随手用一个ConcurrentHashMap也能做缓存看起来比 Redis 省事多了。但一旦应用部署成多实例本地 Map 的问题立刻暴露每个 JVM 进程各自缓存一份数据用户请求打到 A 实例拿到旧值打到 B 实例拿到新值数据对不上。更别提缓存失效时每个实例都要各自回源数据库压力被放大了 N 倍。Redis 解决的正是这个问题它是独立部署的进程所有应用实例共享同一份数据状态。用个生活化的类比——本地 Map 就像每个人手上一张草稿纸Redis 是团队共用的白板谁写都能被所有人看见而且白板自己负责存储、淘汰和持久化。所以第一节课不是学命令是建立Redis 是共享状态层的心智模型。后面所有数据一致性、分布式锁、缓存治理的问题本质上都是在围绕这个共享模型做并发控制。1.2 Redis 作为中间件的常见落地场景从工程角度看Redis 在 Java 项目里至少承担以下几种角色实习生至少要能说出前三类角色典型场景核心命令缓存层热点数据、接口结果缓存GET/SET/EXPIRE分布式锁多实例互斥操作比如库存扣减、定时任务互斥SET NX EX计数器点赞数、访问量、限流窗口计数INCR/DECR排行榜积分榜、热度榜ZADD/ZREVRANGE会话存储集群环境共享 SessionHSET/HGETALL简单队列异步解耦、延迟任务LPUSH/BRPOP这里多说一句类似用 Redis 做消息队列这种事情小流量临时用可以但 Redis 的 List 做队列不保证消息不丢消费者挂了消息就丢了也没有真正的 ACK 机制。生产环境要可靠消息投递还是老老实实上专业 MQ。实习生如果能主动说出Redis 做队列只适合低可靠性场景面试官对这个回答的印象分通常会高不少。2. 五种基础数据类型背命令只是入门用对场景才是进阶Redis 的五种基础数据类型——String、Hash、List、Set、ZSet——是必须过关的。但工程向的要求不止于知道有哪些而是看到业务需求能立刻反应出该用哪种。我把每种类型的工程注意点拆开讲。2.1 String最常见的类型坑也最隐蔽String 能存字符串、数字、二进制数据底层是动态字符串。日常缓存 JSON 字符串就靠它配合 EXPIRE 设置过期时间。除了缓存String 还有三个高频用法计数器INCR是原子操作点赞数、PV 统计、限流都靠它。你写get再set在并发下必然丢更新必须用原子命令。分布式 ID 片段INCRBY生成自增序列配合日期前缀生成订单号。位图统计SETBIT可以做用户签到、在线状态统计一个用户只占 1 bit千万级用户也才 1MB 多。工程里最容易踩的坑是 value 过大。Redis 是单线程处理命令的一个几百 KB 甚至几 MB 的大 key 在网络传输和内存分配上都会阻塞其他命令这就是线上常见的慢查询来源。经验值是单个 value 尽量控制在几十 KB 以内超过 100KB 就要考虑拆分了。另外注意批量操作循环 N 次 SET 会产生 N 次网络 RTT改用MSET/MGET或 Pipeline 能把性能提升一个量级。实习生在代码评审里被提醒这里要合并请求说的基本都是这个。2.2 Hash对象缓存首选省内存但又坑Hash 存的是 field-value 映射特别适合存一个对象的多个字段。比如用户信息你可以用HSET user:1001 name 张三 age 25然后只更新某个字段而不动整个对象。用 Hash 而不是 String 存 JSON 的核心好处一是内存效率当 Hash 字段少的时候Redis 底层用 ziplist 压缩存储比 JSON 字符串省不少内存二是字段级更新改一个字段不用读改写整个 JSON避免并发覆盖。但 Hash 有两个工程注意点第一field 数量超过hash-max-ziplist-entries默认 128后结构会转为 hashtable内存优势消失所以大 Hash要谨慎第二HGETALL会把所有字段一次性拉出来一个大 Hash 的 HGETALL 跟 String 大 key 一样是慢查询来源只取需要的字段用HMGET。2.3 List队列和时间线List 是双向链表左边进右边出天然适合做队列。LPUSHBRPOP的组合就是阻塞队列的经典用法生产者往左 push消费者用BRPOP阻塞等待右侧弹出既省轮询又能实现简单的异步解耦。另一个场景是时间线/消息流比如用户的最近动态用LPUSH把新内容推到队头LRANGE 0 9取最新 10 条配合LTRIM只保留最近 N 条——这比查数据库然后排序高效多了。坑点在上面提过List 做队列不可靠。消费者处理到一半挂了已经弹出的消息就彻底丢了想要至少一次投递得自己引入待确认队列复杂度立刻上来。实习生不要一上来就设计方案用 Redis 做核心队列先评估可靠性要求。2.4 Set去重和集合运算就是它的主场Set 无序、元素唯一交集并集差集是它区别于其他类型的核心能力。场景非常直接点赞/收藏SADD article:123:likes userIdSISMEMBER判断是否点过赞标签系统文章打标签按标签筛选共同好友/关注SINTER user:1:follow user:2:follow一次算出共同关注在线用户去重用户上线SADD下线SREMSCARD拿到在线人数。注意SINTER的时间复杂度是 O(N*M)两个大集合求交会阻塞线上可以先在业务层做集合大小预估或者用SINTERSTORE把结果缓存起来。2.5 ZSet带权重的 Set排行榜和延迟队列都靠它ZSet 每个元素带一个 double 类型的 score按 score 排序。排行榜是它的代表作ZADD leaderboard 100 userAZREVRANGE leaderboard 0 9 WITHSCORES取前 10用户分数更新直接ZINCRBY完全不用你操心排序逻辑。延迟队列也是 ZSet 的杀手锏场景。score 存任务的执行时间戳生产者ZADD delay_queue 任务消费者用一个轮询线程不停ZRANGEBYSCORE delay_queue 0 now LIMIT 0 1取到就处理没取到就睡一会。配合 Lua 脚本做原子取和删就能实现一个轻量延迟队列。很多开源项目里定时任务调度就是这么做的底子。用 ZSet 需要记一个复杂度ZADD是 O(logN)千万级元素的高频写入会带来 CPU 压力。排行榜类需求建议设置合理的冷热分层——只把近一周分数变化的人放进 Redis历史数据归档到数据库。2.6 Key 设计与过期策略新人不重视线上吃大亏面试官很喜欢问一个订单缓存 key 你会怎么设计。标准的工程答案是业务:模块:标识比如order:detail:1001、user:profile:uuid。好处是可读性强按前缀能一眼看出业务归属方便按前缀批量管理虽然不推荐频繁KEYS但前缀能帮你扫出所有相关 key避免不同业务的 key 撞车。过期策略是另一个重点。缓存类 key 几乎都应该设置 TTL否则 Redis 内存慢慢涨最终触发淘汰策略把不该淘汰的数据挤掉。但要注意同一业务的 key 如果设置相同过期时间到点集体失效会导致缓存雪崩所以常见做法是 TTL 加一个随机偏移。实习生如果能主动说出过期时间加 300~600 秒随机值就说明真想过这个问题。3. 工程向必踩的坑序列化、连接配置与可视化工具这节的内容是新手最容易懵、老手闭着眼也能答的区域。几乎每个实习生第一次用 Spring Data Redis 都会遇到乱码、超时、连不上这些问题我把常见坑位挨个排一遍。3.1 Spring Data Redis 序列化乱码key 变成 \xAC\xED 之谜实习生态最经典的灵异事件用 RedisTemplate 存了一个 key打开桌面管理工具一看key 显示成一串乱码\xAC\xED\x00\x05t\x00\x03xxx这种而用命令行直接 SET 的值又读不出来。原因很明确Spring Data Redis 默认的序列化器是JdkSerializationRedisSerializerkey 和 value 都经过 Java 对象序列化这个序列化产物以\xAC\xED开头。你肉眼看到的字符串 key在 Redis 里存的是经过 JDK 序列化嵌套的字节数组。解决思路是覆盖默认配置让 key 用字符串序列化value 用 JSON 序列化Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }这里有两个细节要提醒。第一GenericJackson2JsonRedisSerializer序列化对象时会带上class类型信息反序列化才能还原具体类型但这也意味着如果类的全限定名变了老数据会反序列化失败。第二项目里如果同时用了StringRedisTemplate和RedisTemplate必须保证 key 的序列化方式一致否则互相读不到数据。StringRedisTemplate默认就是 String 序列化你只要让 RedisTemplate 的 key 也用 String 序列化两边就能打通。3.2 连接超时与 Lettuce 的坑RedisCommandTimeoutExceptionSpring Boot 2.x 之后默认用的是 Lettuce 客户端。实习生线上最常见的报错长这样io.lettuce.core.RedisCommandTimeoutException: Command timed out after 10 second(s)看到这个不要急着怀疑 Redis 挂了先按顺序排查第一Redis 服务端打满。Redis 单线程处理命令如果有大 key 慢查询后续所有命令排队客户端等待超时。用redis-cli --latency和SLOWLOG GET确认是否存在慢命令。第二Lettuce 的连接池配置不合理。这里是最容易踩的Lettuce 默认基于 Netty 的共享连接理论上单连接可以并发但 Spring Boot 2.x 某些版本里如果大量线程阻塞在同一个连接上等待响应仍然会超时。这时候需要显式配置连接池spring: data: redis: host: localhost port: 6379 timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 max-wait: 3s注意timeout不要设置得太长否则调用方线程会长时间阻塞。3 秒是比较保险的工程值配合熔断降级比无限等下去健康得多。第三业务线程池被打满。如果调用 Redis 的线程池比如 Tomcat 请求线程全部阻塞在 Redis IO 等待上新请求进不来现象看起来也是连接超时。用jstack看线程栈凡是大量WAITING在 Lettuce 的 Future 上的基本就是慢查询导致的雪崩。3.3 安装与连接工具别在环境上浪费一上午实习生入职第一天经常被装环境卡住我直接给最快路径macOSbrew install redis然后brew services start redis默认端口 6379Windows官方不提供原生版本用 WSL 装 Linux 版或者用 Memurai 这类兼容实现。别下那些来路不明的Windows 版 redis.exe安全性没保障Docker 部署主从这是生产最常用的方式一条命令起一个从节点# 主节点 docker run -d --name redis-master -p 6379:6379 redis:7 redis-server --appendonly yes # 从节点注意在容器内执行主从复制 docker run -d --name redis-slave -p 6380:6379 redis:7 redis-server --slaveof 主节点IP 6379--slaveof虽然在新版本改叫--replicaof了但老的参数依然兼容很多网上教程还在用直接抄没问题。主从的意义在于读写分离和数据冗余但注意主从是异步复制主节点挂了没切换的话数据可能有秒级丢失想要高可用还得上哨兵或集群。连接工具方面Redis Desktop Manager 是老牌 GUI但新版商用收费免费用户可以选开源替代 Another Redis Desktop Manager功能基本够用连接配置、key 树形浏览、命令行一应俱全。实习生装上之后一定要会做一件事切换 DB 和搜索 key排查问题能快很多。4. 分布式锁面试必问工程必用分布式锁大概是面试里被问得最多的 Redis 场景同时也是工程上最容易出问题的点。我按从简单实现到成熟方案的顺序讲顺带把每一层为什么升级说清楚。4.1 为什么需要分布式锁单机多线程下你可以用synchronized或ReentrantLock保证互斥。但多实例部署后两个 JVM 进程里的线程不再共享锁对象Java 原生的锁管不到别的机器上的线程。比如秒杀扣库存两个实例同时读到库存 10各自减一最终库存变成 9这就是超卖。分布式锁的本质是用一个所有实例都能访问到的标记谁抢到标记谁执行。Redis 因为高性能和原子命令成了实现这个标记最常用的载体。4.2 基于 SET NX EX 的正确姿势早期网上教程写的是先SETNX key value再EXPIRE key 30。这个方案有个致命问题两步不是原子的如果 SETNX 成功但 EXPIRE 的时候进程崩溃锁就永远不会释放所有线程被卡死。正确做法是单条原子命令// 加锁key 不存在才设置成功同时设置过期时间 Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(30));这里有两个关键点。第一value必须放一个全局唯一的标识比如 UUID 或 requestId。为什么因为要防止误删别人的锁。线程 A 持有锁超时了锁自动过期线程 B 拿到锁开始执行此时 A 终于执行完如果它直接DEL lockKey把 B 的锁给删了C 又拿到锁三个线程同时执行临界区。正确的释放逻辑是先比对 value 是自己的才删而且比对删除要用 Lua 保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end第二过期时间设多少设短了业务没执行完锁就断了设长了没拿到锁的线程等太久。工程上常见的做法是设置一个预计业务耗时的 3~5 倍作为兜底同时配合续期机制而不是试图给一个完美值。4.3 锁过期了怎么办看门狗续期与 Redisson业务执行时间是不可预测的锁 30 秒过期但业务跑了 50 秒临界区就直接失守了。怎么解决答案是自动续期。Redisson 的解决方案非常优雅加锁后后台有一个 watch dog看门狗线程默认每 10 秒检查一次如果锁还持有且业务没结束就把锁的过期时间重置为 30 秒。业务完成释放锁看门狗线程随之关闭。实习生面试被问到分布式锁怎么续期能说出 Redisson 的看门狗机制就是加分项。但要注意Redisson 的看门狗默认只在持有锁的线程还活着时续期线程挂了锁自然过期不会死锁。千万不要自己写一个 while 循环盲目续期那就是给自己埋雷。Redission 的用法很简单RLock lock redissonClient.getLock(order:pay:1001); boolean locked lock.tryLock(5, 30, TimeUnit.SECONDS); if (locked) { try { // 业务逻辑 } finally { lock.unlock(); } }至于 RedLock多节点加锁算法我的建议是新人不碰为妙。它依赖多个独立 Redis 节点同时加锁成功工程上引入了额外复杂度和时钟依赖业界对它的争论也一直没有定论。大多数业务场景里单节点 Redis Redisson 已经足够真要那么高的可靠性不如上 ZooKeeper 或 etcd 的分布式锁。4.4 锁之外必须补的课幂等性兜底分布式锁不是万能的。锁可以保护临界区互斥但网络抖动、超时重试、消息重复投递这些场景锁根本管不住。真正可靠的做法是锁幂等性双保险业务操作设计成天然幂等或者建一张去重表用数据库唯一索引兜底。举一个真实的例子支付回调里要更新订单状态用 Redis 锁保证了同一订单的多次回调不会并发处理。但万一锁超时了呢万一 Redis 出了网络问题呢此时第二次回调又进来了更新语句重复执行两次。如果更新逻辑本身是状态机校验只有待支付才允许变成已支付或者数据库层面有幂等键约束就不会出大乱子。所以经验丰富的架构师常说的那句话是锁是性能方案幂等才是正确性方案。5. 缓存治理穿透、击穿、雪崩与数据一致性缓存能扛住大量读请求但它也把一致性这个难题带进来了。工程上最经典的三类问题和一套一致性方案面试官百问不厌线上也百踩不厌。5.1 缓存穿透查了一个不存在的东西缓存穿透很简单请求一个缓存里没有、数据库里也不存在的 key比如恶意攻击者拿一串不存在的 ID 循环请求。缓存查不到只能去查数据库数据库也没有于是缓存永远写不进去每次请求都打穿到 DB。高并发下数据库直接被拖垮。两个常用解法空值缓存查不到也往 Redis 写一个空值或特殊标记TTL 设置短一点比如 60 秒。后续同样的请求直接命中空值缓存不再穿透。缺点是冷数据会占据一定内存但通常可控。布隆过滤器启动时把存在的 ID 全部加载到布隆过滤器里请求来了先判断这个 ID 是否存在不存在直接拒绝。布隆过滤器可能误判说存在但实际不存在但绝不会漏判说不存在就是真不存在所以它能挡住绝大多数无效请求。注意布隆过滤器本身需要维护数据频繁增删时要考虑同步成本。工程上两者经常配合布隆过滤器做第一层拦截空值缓存做第二层兜底。5.2 缓存击穿热点 key 过期的一瞬间击穿和穿透的区别很多人搞混。击穿是指一个超高热度的 key比如热搜词、爆款商品突然过期了同一瞬间有几千个请求涌进来全部穿透到数据库。数据库被压垮而 Redis 里根本来不及写入新值。经典解法是互斥重建当缓存 miss 时不是所有线程都去查库而是先尝试获取一个分布式锁或 JVM 内锁只有一个线程去查库并回填缓存其他线程短暂等待后直接读取缓存。String value redis.get(key); if (value null) { // 加锁只让一个线程去重建缓存 if (lock.tryLock()) { try { value db.query(key); redis.set(key, value, ttl); } finally { lock.unlock(); } } else { // 或其他线程 sleep 后重试读缓存 } }逻辑简单但要说清为什么是重建而不是永久不过期——热点 key 设置逻辑过期value 里存业务过期时间可以避免物理过期瞬间的冲击但会引入返回旧数据的容忍期。两个方案各有权衡面试时能说出取舍就行。5.3 缓存雪崩一大片 key 同时失效雪崩是击穿的放大版大量 key 在同一时间过期或者 Redis 实例整体宕机导致所有请求全部落到数据库。这比击穿更难处理因为它是成片的。工程手段过期时间加随机偏移避免同一批 key 集体到点做多级缓存本地 Caffeine 做 L1Redis 做 L2L1 兜住短时流量Redis 高可用持久化 主从 哨兵实例挂了尽快恢复业务降级数据库扛不住时直接返回默认值或限流而不是把 DB 打死。实习生最容易理解的是加随机偏移这招实施成本最低redis.set(key, value, 60 new Random().nextInt(600))。但面试时如果能补一句雪崩的防御要分层过期时间、多级缓存、实例高可用深度就出来了。5.4 缓存与数据库一致性先删缓存还是先更新库这是老生常谈但依然让新人头大的问题。业界最流行的是 Cache Aside Pattern旁路缓存规则就两句话读的时候先读缓存miss 再读库并回填写的时候先更新数据库再删除缓存。为什么不先删缓存再更新库因为删缓存后、更新库前这扇窗口里如果有读请求进来拿到数据库旧值写回缓存就把脏值缓存住了。先更新库再删缓存也一样有窗口但概率更小——更新库成功后、删缓存失败前缓存里还是旧值。解决删缓存失败的办法是引入重试把删除失败的消息丢到消息队列后台慢慢重试。更严格一点的做法是延迟双删先更新数据库删除缓存然后延迟几百毫秒再删一次。目的是把读请求回填旧值这种可能的脏数据窗口内再清理一遍。但双删不是银弹延迟时间定多少、业务容忍多少不一致都得具体分析。我个人在实践中更推荐另一种思路不追求强一致而是让数据尽快趋近一致。方式包括监听数据库 binlog用 Canal 之类变更发生后再主动失效缓存。这样即使应用层某次删除失败了binlog 订阅最终也会把缓存清掉一致性由最终两个字兜住。对于绝大多数业务场景最终一致性完全够用。6. 排障速查实习生常问的问题我都整理成了表最后这部分是实战记录。很多问题实习生刚入职遇到会慌我把高频项按现象、原因、排查手段、解决整理成速查表直接抄作业就行。故障现象可能原因排查手段解决方向缓存 key 是乱码\xAC\xED用了 JDK 默认序列化器看 RedisTemplate 配置key 改用 StringRedisSerializerRedisCommandTimeoutException大 key 慢查询 / 连接池耗尽 / 网络抖动SLOWLOG GET、redis-cli --latency、jstack拆分大 key、配置连接池、缩短 timeout内存暴涨未设置 TTL / 大 key / 淘汰策略不当INFO memory、redis-cli --bigkeys设置过期时间、拆分大 key、配置 maxmemory删了数据库但缓存还是旧值先删缓存后更新库的窗口期看业务写入顺序改为 Cache Aside 先更新库再删缓存多个实例同时执行定时任务缺少分布式互斥日志看执行时间重叠加分布式锁缓存命中率低过期时间太短 / 大量 empty keyINFO stats看 keyspace_hits拉长 TTL、空值也缓存主从切换后数据缺失异步复制有延迟INFO replication看 master_repl_offset接受秒级丢失或换强一致方案6.1 内存淘汰与持久化两个必背的配置维度不设置maxmemory的 Redis 就像一个没有回收机制的垃圾桶满了之后继续写会直接报 OOM。工程上通常会设置上限并指定淘汰策略。常见的有allkeys-lru所有 key 按 LRU 淘汰、allkeys-lfu按访问频率淘汰、volatile-ttl优先淘汰 TTL 短的。选型原则是缓存场景更看重最近最常访问就用 LRU 或 LFU如果你的 Redis 里有不能丢的数据那就别用 allkeys 系列的淘汰策略避免把非缓存数据清掉。持久化上RDB快照恢复快但丢数据窗口大按快照间隔丢AOF追加日志最多丢一秒取决于 always/everysec 策略但文件大、恢复慢。工程实践通常是两者都开RDB 用于快速重启AOF 用于兜底数据同时设置appendfsync everysec做性能和可靠性的折中。这些配好之后INFO persistence能查到最近持久化状态线上排查必备。6.2 SCAN 而非 KEYS大键空间扫描的正确姿势实习生排查线上 Redis 时第一反应往往是KEYS user:*把所有 key 捞出来。KEYS命令会阻塞 Redis 单线程直到返回全部结果线上几百万 key 一敲Redis 直接卡住几秒这是禁止在生产执行的。替代方案是SCAN cursor它每次返回一小批 key默认 10 个左右和一个新游标循环迭代直到游标返回 0。它不阻塞 Redis虽然可能在迭代期间 key 有变化导致结果不精确但用于日常排查完全够用。同样的思路也适用HSCAN、SSCAN、ZSCAN。如果有条件更规范的做法是部署 Redis 的监控采集比如 Prometheus redis_exporter把 key 数量、内存、命中率都做成指标不想排查的时候才临时 SCAN。6.3 一条面试加分但工程更值钱的原则先看慢查询再谈优化我想说的最后一件事是实习生 debug 性能问题不要上来就猜测。Redis 提供SLOWLOG GET 10一条命令就能看到最近 10 个慢命令及耗时。凡是超过slowlog-log-slower-than默认 10000 微秒的都会被记录下来。实际排障中大量超时问题根源就是某条大集合操作或大 key 读写。先看慢查询对症下药而不是盲目重启、盲目调超时参数。根据我个人带实习生的经验Redis 这块的成长路径特别清晰第一周能背命令和数据类型的场景第一月能在真实 bug 里认出序列化乱码和超时问题第一年能独立设计一套缓存治理方案和分布式锁。关键是每次踩坑之后把现象、原因、排查手段记下来形成自己的排障手册。这篇文章里的速查表你完全可以直接复制进自己的笔记持续往里补——等你补满了几十条真实案例Redis 对你来说就不再是面试考点而是真正的工程工具。 
长河君 · 2026/10/10 19:15:26 · 阅读 1.2k Java工程中Redis实战避坑指南：从数据类型到分布式锁
带过不少实习生也面试过不少应届生Redis 问一圈基本就能摸清一个人的工程底子。问数据类型能背出五种但一问到序列化乱码、缓存击穿、分布式锁续期十个人里有八个开始含糊。这篇东西不是把 Redis 官方文档再抄一遍而是站在 Java 后端工程的角度把实习生入职后真正会碰到、线上容易踩坑的那些知识点串一遍数据类型怎么选、序列化为什么乱码、连接超时怎么排查、分布式锁怎么落地、缓存三大问题和一致性怎么处理。全程用项目里真实发生的场景说话看完直接能用到你的 demo 和第一个线上需求里。1. 先想明白Redis 在 Java 工程里到底扮演什么角色很多实习生上来就敲命令SET 一个值然后 GET 回来觉得自己会 Redis 了。但工程里 Redis 从来不孤立存在它是因为解决某个真实问题才被引入的。先把这个为什么想清楚后面所有知识点才有落点。1.1 为什么是 Redis 而不是本地 Map你写单机 demo 的时候随手用一个ConcurrentHashMap也能做缓存看起来比 Redis 省事多了。但一旦应用部署成多实例本地 Map 的问题立刻暴露每个 JVM 进程各自缓存一份数据用户请求打到 A 实例拿到旧值打到 B 实例拿到新值数据对不上。更别提缓存失效时每个实例都要各自回源数据库压力被放大了 N 倍。Redis 解决的正是这个问题它是独立部署的进程所有应用实例共享同一份数据状态。用个生活化的类比——本地 Map 就像每个人手上一张草稿纸Redis 是团队共用的白板谁写都能被所有人看见而且白板自己负责存储、淘汰和持久化。所以第一节课不是学命令是建立Redis 是共享状态层的心智模型。后面所有数据一致性、分布式锁、缓存治理的问题本质上都是在围绕这个共享模型做并发控制。1.2 Redis 作为中间件的常见落地场景从工程角度看Redis 在 Java 项目里至少承担以下几种角色实习生至少要能说出前三类角色典型场景核心命令缓存层热点数据、接口结果缓存GET/SET/EXPIRE分布式锁多实例互斥操作比如库存扣减、定时任务互斥SET NX EX计数器点赞数、访问量、限流窗口计数INCR/DECR排行榜积分榜、热度榜ZADD/ZREVRANGE会话存储集群环境共享 SessionHSET/HGETALL简单队列异步解耦、延迟任务LPUSH/BRPOP这里多说一句类似用 Redis 做消息队列这种事情小流量临时用可以但 Redis 的 List 做队列不保证消息不丢消费者挂了消息就丢了也没有真正的 ACK 机制。生产环境要可靠消息投递还是老老实实上专业 MQ。实习生如果能主动说出Redis 做队列只适合低可靠性场景面试官对这个回答的印象分通常会高不少。2. 五种基础数据类型背命令只是入门用对场景才是进阶Redis 的五种基础数据类型——String、Hash、List、Set、ZSet——是必须过关的。但工程向的要求不止于知道有哪些而是看到业务需求能立刻反应出该用哪种。我把每种类型的工程注意点拆开讲。2.1 String最常见的类型坑也最隐蔽String 能存字符串、数字、二进制数据底层是动态字符串。日常缓存 JSON 字符串就靠它配合 EXPIRE 设置过期时间。除了缓存String 还有三个高频用法计数器INCR是原子操作点赞数、PV 统计、限流都靠它。你写get再set在并发下必然丢更新必须用原子命令。分布式 ID 片段INCRBY生成自增序列配合日期前缀生成订单号。位图统计SETBIT可以做用户签到、在线状态统计一个用户只占 1 bit千万级用户也才 1MB 多。工程里最容易踩的坑是 value 过大。Redis 是单线程处理命令的一个几百 KB 甚至几 MB 的大 key 在网络传输和内存分配上都会阻塞其他命令这就是线上常见的慢查询来源。经验值是单个 value 尽量控制在几十 KB 以内超过 100KB 就要考虑拆分了。另外注意批量操作循环 N 次 SET 会产生 N 次网络 RTT改用MSET/MGET或 Pipeline 能把性能提升一个量级。实习生在代码评审里被提醒这里要合并请求说的基本都是这个。2.2 Hash对象缓存首选省内存但又坑Hash 存的是 field-value 映射特别适合存一个对象的多个字段。比如用户信息你可以用HSET user:1001 name 张三 age 25然后只更新某个字段而不动整个对象。用 Hash 而不是 String 存 JSON 的核心好处一是内存效率当 Hash 字段少的时候Redis 底层用 ziplist 压缩存储比 JSON 字符串省不少内存二是字段级更新改一个字段不用读改写整个 JSON避免并发覆盖。但 Hash 有两个工程注意点第一field 数量超过hash-max-ziplist-entries默认 128后结构会转为 hashtable内存优势消失所以大 Hash要谨慎第二HGETALL会把所有字段一次性拉出来一个大 Hash 的 HGETALL 跟 String 大 key 一样是慢查询来源只取需要的字段用HMGET。2.3 List队列和时间线List 是双向链表左边进右边出天然适合做队列。LPUSHBRPOP的组合就是阻塞队列的经典用法生产者往左 push消费者用BRPOP阻塞等待右侧弹出既省轮询又能实现简单的异步解耦。另一个场景是时间线/消息流比如用户的最近动态用LPUSH把新内容推到队头LRANGE 0 9取最新 10 条配合LTRIM只保留最近 N 条——这比查数据库然后排序高效多了。坑点在上面提过List 做队列不可靠。消费者处理到一半挂了已经弹出的消息就彻底丢了想要至少一次投递得自己引入待确认队列复杂度立刻上来。实习生不要一上来就设计方案用 Redis 做核心队列先评估可靠性要求。2.4 Set去重和集合运算就是它的主场Set 无序、元素唯一交集并集差集是它区别于其他类型的核心能力。场景非常直接点赞/收藏SADD article:123:likes userIdSISMEMBER判断是否点过赞标签系统文章打标签按标签筛选共同好友/关注SINTER user:1:follow user:2:follow一次算出共同关注在线用户去重用户上线SADD下线SREMSCARD拿到在线人数。注意SINTER的时间复杂度是 O(N*M)两个大集合求交会阻塞线上可以先在业务层做集合大小预估或者用SINTERSTORE把结果缓存起来。2.5 ZSet带权重的 Set排行榜和延迟队列都靠它ZSet 每个元素带一个 double 类型的 score按 score 排序。排行榜是它的代表作ZADD leaderboard 100 userAZREVRANGE leaderboard 0 9 WITHSCORES取前 10用户分数更新直接ZINCRBY完全不用你操心排序逻辑。延迟队列也是 ZSet 的杀手锏场景。score 存任务的执行时间戳生产者ZADD delay_queue 任务消费者用一个轮询线程不停ZRANGEBYSCORE delay_queue 0 now LIMIT 0 1取到就处理没取到就睡一会。配合 Lua 脚本做原子取和删就能实现一个轻量延迟队列。很多开源项目里定时任务调度就是这么做的底子。用 ZSet 需要记一个复杂度ZADD是 O(logN)千万级元素的高频写入会带来 CPU 压力。排行榜类需求建议设置合理的冷热分层——只把近一周分数变化的人放进 Redis历史数据归档到数据库。2.6 Key 设计与过期策略新人不重视线上吃大亏面试官很喜欢问一个订单缓存 key 你会怎么设计。标准的工程答案是业务:模块:标识比如order:detail:1001、user:profile:uuid。好处是可读性强按前缀能一眼看出业务归属方便按前缀批量管理虽然不推荐频繁KEYS但前缀能帮你扫出所有相关 key避免不同业务的 key 撞车。过期策略是另一个重点。缓存类 key 几乎都应该设置 TTL否则 Redis 内存慢慢涨最终触发淘汰策略把不该淘汰的数据挤掉。但要注意同一业务的 key 如果设置相同过期时间到点集体失效会导致缓存雪崩所以常见做法是 TTL 加一个随机偏移。实习生如果能主动说出过期时间加 300~600 秒随机值就说明真想过这个问题。3. 工程向必踩的坑序列化、连接配置与可视化工具这节的内容是新手最容易懵、老手闭着眼也能答的区域。几乎每个实习生第一次用 Spring Data Redis 都会遇到乱码、超时、连不上这些问题我把常见坑位挨个排一遍。3.1 Spring Data Redis 序列化乱码key 变成 \xAC\xED 之谜实习生态最经典的灵异事件用 RedisTemplate 存了一个 key打开桌面管理工具一看key 显示成一串乱码\xAC\xED\x00\x05t\x00\x03xxx这种而用命令行直接 SET 的值又读不出来。原因很明确Spring Data Redis 默认的序列化器是JdkSerializationRedisSerializerkey 和 value 都经过 Java 对象序列化这个序列化产物以\xAC\xED开头。你肉眼看到的字符串 key在 Redis 里存的是经过 JDK 序列化嵌套的字节数组。解决思路是覆盖默认配置让 key 用字符串序列化value 用 JSON 序列化Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }这里有两个细节要提醒。第一GenericJackson2JsonRedisSerializer序列化对象时会带上class类型信息反序列化才能还原具体类型但这也意味着如果类的全限定名变了老数据会反序列化失败。第二项目里如果同时用了StringRedisTemplate和RedisTemplate必须保证 key 的序列化方式一致否则互相读不到数据。StringRedisTemplate默认就是 String 序列化你只要让 RedisTemplate 的 key 也用 String 序列化两边就能打通。3.2 连接超时与 Lettuce 的坑RedisCommandTimeoutExceptionSpring Boot 2.x 之后默认用的是 Lettuce 客户端。实习生线上最常见的报错长这样io.lettuce.core.RedisCommandTimeoutException: Command timed out after 10 second(s)看到这个不要急着怀疑 Redis 挂了先按顺序排查第一Redis 服务端打满。Redis 单线程处理命令如果有大 key 慢查询后续所有命令排队客户端等待超时。用redis-cli --latency和SLOWLOG GET确认是否存在慢命令。第二Lettuce 的连接池配置不合理。这里是最容易踩的Lettuce 默认基于 Netty 的共享连接理论上单连接可以并发但 Spring Boot 2.x 某些版本里如果大量线程阻塞在同一个连接上等待响应仍然会超时。这时候需要显式配置连接池spring: data: redis: host: localhost port: 6379 timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 max-wait: 3s注意timeout不要设置得太长否则调用方线程会长时间阻塞。3 秒是比较保险的工程值配合熔断降级比无限等下去健康得多。第三业务线程池被打满。如果调用 Redis 的线程池比如 Tomcat 请求线程全部阻塞在 Redis IO 等待上新请求进不来现象看起来也是连接超时。用jstack看线程栈凡是大量WAITING在 Lettuce 的 Future 上的基本就是慢查询导致的雪崩。3.3 安装与连接工具别在环境上浪费一上午实习生入职第一天经常被装环境卡住我直接给最快路径macOSbrew install redis然后brew services start redis默认端口 6379Windows官方不提供原生版本用 WSL 装 Linux 版或者用 Memurai 这类兼容实现。别下那些来路不明的Windows 版 redis.exe安全性没保障Docker 部署主从这是生产最常用的方式一条命令起一个从节点# 主节点 docker run -d --name redis-master -p 6379:6379 redis:7 redis-server --appendonly yes # 从节点注意在容器内执行主从复制 docker run -d --name redis-slave -p 6380:6379 redis:7 redis-server --slaveof 主节点IP 6379--slaveof虽然在新版本改叫--replicaof了但老的参数依然兼容很多网上教程还在用直接抄没问题。主从的意义在于读写分离和数据冗余但注意主从是异步复制主节点挂了没切换的话数据可能有秒级丢失想要高可用还得上哨兵或集群。连接工具方面Redis Desktop Manager 是老牌 GUI但新版商用收费免费用户可以选开源替代 Another Redis Desktop Manager功能基本够用连接配置、key 树形浏览、命令行一应俱全。实习生装上之后一定要会做一件事切换 DB 和搜索 key排查问题能快很多。4. 分布式锁面试必问工程必用分布式锁大概是面试里被问得最多的 Redis 场景同时也是工程上最容易出问题的点。我按从简单实现到成熟方案的顺序讲顺带把每一层为什么升级说清楚。4.1 为什么需要分布式锁单机多线程下你可以用synchronized或ReentrantLock保证互斥。但多实例部署后两个 JVM 进程里的线程不再共享锁对象Java 原生的锁管不到别的机器上的线程。比如秒杀扣库存两个实例同时读到库存 10各自减一最终库存变成 9这就是超卖。分布式锁的本质是用一个所有实例都能访问到的标记谁抢到标记谁执行。Redis 因为高性能和原子命令成了实现这个标记最常用的载体。4.2 基于 SET NX EX 的正确姿势早期网上教程写的是先SETNX key value再EXPIRE key 30。这个方案有个致命问题两步不是原子的如果 SETNX 成功但 EXPIRE 的时候进程崩溃锁就永远不会释放所有线程被卡死。正确做法是单条原子命令// 加锁key 不存在才设置成功同时设置过期时间 Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(30));这里有两个关键点。第一value必须放一个全局唯一的标识比如 UUID 或 requestId。为什么因为要防止误删别人的锁。线程 A 持有锁超时了锁自动过期线程 B 拿到锁开始执行此时 A 终于执行完如果它直接DEL lockKey把 B 的锁给删了C 又拿到锁三个线程同时执行临界区。正确的释放逻辑是先比对 value 是自己的才删而且比对删除要用 Lua 保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end第二过期时间设多少设短了业务没执行完锁就断了设长了没拿到锁的线程等太久。工程上常见的做法是设置一个预计业务耗时的 3~5 倍作为兜底同时配合续期机制而不是试图给一个完美值。4.3 锁过期了怎么办看门狗续期与 Redisson业务执行时间是不可预测的锁 30 秒过期但业务跑了 50 秒临界区就直接失守了。怎么解决答案是自动续期。Redisson 的解决方案非常优雅加锁后后台有一个 watch dog看门狗线程默认每 10 秒检查一次如果锁还持有且业务没结束就把锁的过期时间重置为 30 秒。业务完成释放锁看门狗线程随之关闭。实习生面试被问到分布式锁怎么续期能说出 Redisson 的看门狗机制就是加分项。但要注意Redisson 的看门狗默认只在持有锁的线程还活着时续期线程挂了锁自然过期不会死锁。千万不要自己写一个 while 循环盲目续期那就是给自己埋雷。Redission 的用法很简单RLock lock redissonClient.getLock(order:pay:1001); boolean locked lock.tryLock(5, 30, TimeUnit.SECONDS); if (locked) { try { // 业务逻辑 } finally { lock.unlock(); } }至于 RedLock多节点加锁算法我的建议是新人不碰为妙。它依赖多个独立 Redis 节点同时加锁成功工程上引入了额外复杂度和时钟依赖业界对它的争论也一直没有定论。大多数业务场景里单节点 Redis Redisson 已经足够真要那么高的可靠性不如上 ZooKeeper 或 etcd 的分布式锁。4.4 锁之外必须补的课幂等性兜底分布式锁不是万能的。锁可以保护临界区互斥但网络抖动、超时重试、消息重复投递这些场景锁根本管不住。真正可靠的做法是锁幂等性双保险业务操作设计成天然幂等或者建一张去重表用数据库唯一索引兜底。举一个真实的例子支付回调里要更新订单状态用 Redis 锁保证了同一订单的多次回调不会并发处理。但万一锁超时了呢万一 Redis 出了网络问题呢此时第二次回调又进来了更新语句重复执行两次。如果更新逻辑本身是状态机校验只有待支付才允许变成已支付或者数据库层面有幂等键约束就不会出大乱子。所以经验丰富的架构师常说的那句话是锁是性能方案幂等才是正确性方案。5. 缓存治理穿透、击穿、雪崩与数据一致性缓存能扛住大量读请求但它也把一致性这个难题带进来了。工程上最经典的三类问题和一套一致性方案面试官百问不厌线上也百踩不厌。5.1 缓存穿透查了一个不存在的东西缓存穿透很简单请求一个缓存里没有、数据库里也不存在的 key比如恶意攻击者拿一串不存在的 ID 循环请求。缓存查不到只能去查数据库数据库也没有于是缓存永远写不进去每次请求都打穿到 DB。高并发下数据库直接被拖垮。两个常用解法空值缓存查不到也往 Redis 写一个空值或特殊标记TTL 设置短一点比如 60 秒。后续同样的请求直接命中空值缓存不再穿透。缺点是冷数据会占据一定内存但通常可控。布隆过滤器启动时把存在的 ID 全部加载到布隆过滤器里请求来了先判断这个 ID 是否存在不存在直接拒绝。布隆过滤器可能误判说存在但实际不存在但绝不会漏判说不存在就是真不存在所以它能挡住绝大多数无效请求。注意布隆过滤器本身需要维护数据频繁增删时要考虑同步成本。工程上两者经常配合布隆过滤器做第一层拦截空值缓存做第二层兜底。5.2 缓存击穿热点 key 过期的一瞬间击穿和穿透的区别很多人搞混。击穿是指一个超高热度的 key比如热搜词、爆款商品突然过期了同一瞬间有几千个请求涌进来全部穿透到数据库。数据库被压垮而 Redis 里根本来不及写入新值。经典解法是互斥重建当缓存 miss 时不是所有线程都去查库而是先尝试获取一个分布式锁或 JVM 内锁只有一个线程去查库并回填缓存其他线程短暂等待后直接读取缓存。String value redis.get(key); if (value null) { // 加锁只让一个线程去重建缓存 if (lock.tryLock()) { try { value db.query(key); redis.set(key, value, ttl); } finally { lock.unlock(); } } else { // 或其他线程 sleep 后重试读缓存 } }逻辑简单但要说清为什么是重建而不是永久不过期——热点 key 设置逻辑过期value 里存业务过期时间可以避免物理过期瞬间的冲击但会引入返回旧数据的容忍期。两个方案各有权衡面试时能说出取舍就行。5.3 缓存雪崩一大片 key 同时失效雪崩是击穿的放大版大量 key 在同一时间过期或者 Redis 实例整体宕机导致所有请求全部落到数据库。这比击穿更难处理因为它是成片的。工程手段过期时间加随机偏移避免同一批 key 集体到点做多级缓存本地 Caffeine 做 L1Redis 做 L2L1 兜住短时流量Redis 高可用持久化 主从 哨兵实例挂了尽快恢复业务降级数据库扛不住时直接返回默认值或限流而不是把 DB 打死。实习生最容易理解的是加随机偏移这招实施成本最低redis.set(key, value, 60 new Random().nextInt(600))。但面试时如果能补一句雪崩的防御要分层过期时间、多级缓存、实例高可用深度就出来了。5.4 缓存与数据库一致性先删缓存还是先更新库这是老生常谈但依然让新人头大的问题。业界最流行的是 Cache Aside Pattern旁路缓存规则就两句话读的时候先读缓存miss 再读库并回填写的时候先更新数据库再删除缓存。为什么不先删缓存再更新库因为删缓存后、更新库前这扇窗口里如果有读请求进来拿到数据库旧值写回缓存就把脏值缓存住了。先更新库再删缓存也一样有窗口但概率更小——更新库成功后、删缓存失败前缓存里还是旧值。解决删缓存失败的办法是引入重试把删除失败的消息丢到消息队列后台慢慢重试。更严格一点的做法是延迟双删先更新数据库删除缓存然后延迟几百毫秒再删一次。目的是把读请求回填旧值这种可能的脏数据窗口内再清理一遍。但双删不是银弹延迟时间定多少、业务容忍多少不一致都得具体分析。我个人在实践中更推荐另一种思路不追求强一致而是让数据尽快趋近一致。方式包括监听数据库 binlog用 Canal 之类变更发生后再主动失效缓存。这样即使应用层某次删除失败了binlog 订阅最终也会把缓存清掉一致性由最终两个字兜住。对于绝大多数业务场景最终一致性完全够用。6. 排障速查实习生常问的问题我都整理成了表最后这部分是实战记录。很多问题实习生刚入职遇到会慌我把高频项按现象、原因、排查手段、解决整理成速查表直接抄作业就行。故障现象可能原因排查手段解决方向缓存 key 是乱码\xAC\xED用了 JDK 默认序列化器看 RedisTemplate 配置key 改用 StringRedisSerializerRedisCommandTimeoutException大 key 慢查询 / 连接池耗尽 / 网络抖动SLOWLOG GET、redis-cli --latency、jstack拆分大 key、配置连接池、缩短 timeout内存暴涨未设置 TTL / 大 key / 淘汰策略不当INFO memory、redis-cli --bigkeys设置过期时间、拆分大 key、配置 maxmemory删了数据库但缓存还是旧值先删缓存后更新库的窗口期看业务写入顺序改为 Cache Aside 先更新库再删缓存多个实例同时执行定时任务缺少分布式互斥日志看执行时间重叠加分布式锁缓存命中率低过期时间太短 / 大量 empty keyINFO stats看 keyspace_hits拉长 TTL、空值也缓存主从切换后数据缺失异步复制有延迟INFO replication看 master_repl_offset接受秒级丢失或换强一致方案6.1 内存淘汰与持久化两个必背的配置维度不设置maxmemory的 Redis 就像一个没有回收机制的垃圾桶满了之后继续写会直接报 OOM。工程上通常会设置上限并指定淘汰策略。常见的有allkeys-lru所有 key 按 LRU 淘汰、allkeys-lfu按访问频率淘汰、volatile-ttl优先淘汰 TTL 短的。选型原则是缓存场景更看重最近最常访问就用 LRU 或 LFU如果你的 Redis 里有不能丢的数据那就别用 allkeys 系列的淘汰策略避免把非缓存数据清掉。持久化上RDB快照恢复快但丢数据窗口大按快照间隔丢AOF追加日志最多丢一秒取决于 always/everysec 策略但文件大、恢复慢。工程实践通常是两者都开RDB 用于快速重启AOF 用于兜底数据同时设置appendfsync everysec做性能和可靠性的折中。这些配好之后INFO persistence能查到最近持久化状态线上排查必备。6.2 SCAN 而非 KEYS大键空间扫描的正确姿势实习生排查线上 Redis 时第一反应往往是KEYS user:*把所有 key 捞出来。KEYS命令会阻塞 Redis 单线程直到返回全部结果线上几百万 key 一敲Redis 直接卡住几秒这是禁止在生产执行的。替代方案是SCAN cursor它每次返回一小批 key默认 10 个左右和一个新游标循环迭代直到游标返回 0。它不阻塞 Redis虽然可能在迭代期间 key 有变化导致结果不精确但用于日常排查完全够用。同样的思路也适用HSCAN、SSCAN、ZSCAN。如果有条件更规范的做法是部署 Redis 的监控采集比如 Prometheus redis_exporter把 key 数量、内存、命中率都做成指标不想排查的时候才临时 SCAN。6.3 一条面试加分但工程更值钱的原则先看慢查询再谈优化我想说的最后一件事是实习生 debug 性能问题不要上来就猜测。Redis 提供SLOWLOG GET 10一条命令就能看到最近 10 个慢命令及耗时。凡是超过slowlog-log-slower-than默认 10000 微秒的都会被记录下来。实际排障中大量超时问题根源就是某条大集合操作或大 key 读写。先看慢查询对症下药而不是盲目重启、盲目调超时参数。根据我个人带实习生的经验Redis 这块的成长路径特别清晰第一周能背命令和数据类型的场景第一月能在真实 bug 里认出序列化乱码和超时问题第一年能独立设计一套缓存治理方案和分布式锁。关键是每次踩坑之后把现象、原因、排查手段记下来形成自己的排障手册。这篇文章里的速查表你完全可以直接复制进自己的笔记持续往里补——等你补满了几十条真实案例Redis 对你来说就不再是面试考点而是真正的工程工具。