1. 项目里Redis的存在感它不只是缓存更是Java服务的“共享内存层”我在不同规模的Java项目里待过不少时间几乎每个跑得起来的服务都挂着Redis。轻的用它做缓存、存验证码、存会话重的直接让它扛分布式锁、排行榜、限流器、甚至临时消息队列。很多人在简历上写“熟悉Redis”但被追问“你的项目里Redis到底解决了什么问题”时往往只答出一句“缓存热点数据”。这个回答不算错但远没有触到本质。1.1 数据库扛不住的热点流量Redis是怎么接住的想象一个商品详情页的秒杀场景查询请求如果全部打到MySQL上连接数很快被占满磁盘IO飙升即使加了索引也可能被慢查询拖死。MySQL承接几万QPS已经压力很大到了十几万QPS基本要扩容、拆库、上中间件成本一下就上去了。而Redis是纯内存操作单实例轻松扛十万级QPS配合集群还能往上走。我常用一个生活化的类比去理解这件事MySQL像一个大仓库啥都能存但每次取货都要翻箱倒柜仓库门口还只有一个管理员负责登记。Redis则像一个放在车间门口的常用零件柜东西不多但全都是高频率用到的一伸手就能拿到。Java服务的高并发读写路径上把“读多写少”的数据放到Redis就是把常用零件放进车间门口的柜子里。实际项目中我会把用户信息、商品基本信息、配置字典、验证码这类高频数据放进Redis数据库只作为最终一致性的数据源。等流量高峰过去或者缓存被主动淘汰数据再从MySQL回源这就是经典的Cache Aside模式。1.2 Redis不是万能的缓存一致性、持久化和“大KEY”是三道分水岭Redis再快它也替换不了数据库。项目里如果出现缓存和数据库不一致多半不是Redis的问题而是更新策略设计得不对。比如我先更新数据库再删缓存删除动作失败旧缓存就一直在我先把缓存删了再更新数据库中间一瞬间会有并发请求把旧数据读回缓存里。这些都是我在项目里真实踩过的坑后文会专门展开。持久化也是一个分水岭。Redis默认有RDB快照和AOF日志两种持久化方式但如果配置成纯内存、不持久化机器重启后数据就没了。很多团队用Redis只做缓存丢了就丢了问题不大但一旦用它存分布式ID、库存数字这类有业务含义的数据持久化策略就必须认真检查。另一个容易被忽略的点是“大KEY”。我见过有人把十兆级别的JSON字符串直接塞进Redis读的时候没问题写的时候慢删除的时候更慢还会阻塞其他命令执行。我在线上排查过几次接口超时最后定位全是清理大KEY造成的Redis阻塞。这个问题后面我会给出具体的排查命令。2. 环境准备与客户端选型安装、三步选型、序列化乱码很多初学者第一关就卡在环境上。Redis的安装看似简单但不同系统的坑不太一样。我按主流场景梳理一遍顺便把Java客户端的选择逻辑说清楚。2.1 各平台安装实测Linux、macOS、Windows分别怎么弄Linux服务器上最直接的方式是用包管理器。CentOS系列用yumUbuntu/Debian系列用apt。但要注意部分系统的默认源里Redis版本比较老比如CentOS 7带的可能是3.2功能落后且存在已知问题。我习惯的步骤是去Redis官网下载稳定版源码包比如redis-7.2.x.tar.gz上传到服务器后解压进入目录执行make编译完成后把src目录下的redis-server和redis-cli复制到/usr/local/bin新建配置文件目录比如/etc/redis把redis.conf放进去设置daemonize yes和requirepass开启密码。macOS下最省事的是Homebrewbrew install redis装完直接redis-server启动。想开机自启可以brew services start redis这个命令会把Redis注册成后台服务重启电脑后还在跑实际用起来很顺手。Windows原生不支持Redis但国内很多人习惯下载Windows编译版。需要提醒的是官方仓库里没有正版Windows版网上那些Win版都是社区维护的老版本稳定性参差不齐。我现在更推荐两种方案本机装WSL在Linux子系统里跑Redis或者直接用Docker跑redis镜像。公司生产环境用Linux开发环境用WSL或Docker能最大限度保证行为一致。2.2 Jedis、Lettuce、Redisson怎么选一张对比表说清楚Java生态里Redis客户端现在主流就三个Jedis、Lettuce、Redisson。还真是不少人不清楚它们之间的区别面试也常问。客户端底层模式核心特点适用场景Jedis同步阻塞轻量API最接近Redis原生命令连接池需要自行管理集群模式支持一般小项目、对性能要求不极端的常规CRUDLettuce异步非阻塞基于Netty支持同步/异步/响应式连接共享Spring Boot默认集成大部分Spring Boot项目并发高但要省连接数Redisson封装高内置分布式锁、分布式集合、延迟队列等高级API屏蔽了很多Red is原生细节分布式场景需要锁、布隆、限流器时优先我的建议很简单如果你用的是Spring Boot默认Lettuce就够不需要额外替换如果你需要分布式锁直接引入Redisson它内部调度做得非常成熟如果你只是写个工具类或者对Redis原生命令熟悉Jedis也可以但要记得手动配连接池不然每次请求都新建连接性能和资源都会有明显问题。很多公司在面试时喜欢问“为什么Spring Boot默认用Lettuce而不是Jedis”我的理解是Lettuce基于Netty实现了连接复用一个连接可以并发多个请求比Jedis一个请求占一个连接更适合高并发而且Lettuce天然支持Redis Cluster、异步和响应式编程后续扩展更平滑。2.3 Spring Data Redis序列化乱码这是我被坑得最久的一个点如果你用Spring Data Redis存对象必然绕不开序列化问题。默认的JdkSerializationRedisSerializer会把对象序列化成一长串乱七八糟的二进制存进Redis后肉眼完全不可读且字节占用还大。我用Redis Desktop Manager看数据时看到一堆“\xAC\xED\x00\x05t...”开头的乱码头都是大的。后来我统一用这种方式处理key统一用StringRedisSerializer保证key是可见的、可检索的value根据场景决定简单的JSON对象用GenericJackson2JsonRedisSerializer存的时候自动转JSON需要二进制流的场景直接用Jdk序列化或自定义序列化器如果是敏感字段我会先做脱敏再序列化避免把明文关键信息直接落进Redis。我的经验是key的命名规范直接影响排障效率。建议统一格式比如 bizName:entityName:field:value像 order:user:123一眼看出是哪条业务的哪个用户。不规范的key一旦堆了几百万个连查都不好查。3. 五大基本数据类型的Java实战从计数器到排行榜Redis有String、Hash、List、Set、ZSet五种基础类型每一个在Java项目里都有非常具体的落地场景。我一个个说顺便把操作代码写出来。3.1 String验证码、计数器、分布式IDString是最常用的类型存验证码、token、对象JSON、计数器都靠它。验证码这个场景我习惯设置5分钟过期用redisTemplate.set(key, code, 5, TimeUnit.MINUTES)。校验时先读缓存判断是否一致校验成功立刻删除防止同一个验证码二次使用。这个逻辑看着简单但很多项目漏了“再删一次”这个动作导致验证码能在5分钟内反复用被安全测试抓到过。计数器适合做点赞数、浏览量。用incr和decr原子操作比先读后写在并发下安全得多。比如Long likes redisTemplate.opsForValue().increment(article:like:123, 1);这种操作注定了不会出现超卖因为Redis单线程执行命令incr本身就是原子的。另外我常用String的setNx做分布式ID的简单前缀虽然现在有雪花算法但轻量场景下用incr生成自增序号也完全够用。3.2 Hash用户信息缓存、购物车这类“对象型”数据Hash适合存结构化的对象字段。比如用户信息我是这么用的redisTemplate.opsForHash().put(user:info:1001, name, 张三); redisTemplate.opsForHash().put(user:info:1001, level, VIP3);好处是HashMap的单个字段可以单独更新不用把整个对象序列化成字符串再写回去。比如用户改了昵称只更新“name”字段就行不搞全量覆盖写放大就小很多。购物车是Hash的经典场景。每个用户的购物车是一个key商品ID是field商品数量是value。用户一个一个加购物车时就用hIncrBy在对应field上加数量最终结算时hgetAll一次性取出整个购物车。相比存一个巨大的JSONHash的扩展性、可读性都更好。3.3 List简易消息队列、最新公告列表List左进右出天然FIFO队列。项目规模不大时可以不引入MQ直接用list做轻量消息队列// 生产者 redisTemplate.opsForList().leftPush(queue:order:paid, orderId); // 消费者 String orderId redisTemplate.opsForList().rightPop(queue:order:paid, 10, TimeUnit.SECONDS);rightPop支持阻塞等待消费端没有消息时会挂起最多10秒而不是空转这对没有MQ但想削峰的小项目很友好。另一个场景是存最近公告或最新评论。用lTrim限制list长度只保留最近100条每次新推送时先把旧的不需要的裁掉数据量不会无限膨胀。3.4 Set去重、公共标签、在线状态Set天然去重适合做“是否参与过活动”“已经点赞过的用户列表”以及“共同好友”这类集合计算。我用过的一个比较典型的场景是给文章打标签。每篇文章对应一个set存储所有标签名。查某个标签下所有文章时反向再维护一个“标签名-文章ID集合”用sinter对多个标签做交集就能实现“同时包含标签A和标签B的文章”这种筛选。在线状态也可以用Set做用户上线时sAdd进online_users下线时sRemove在线人数直接scard查询非常轻量。3.5 ZSet排行榜、积分榜、限流滑动窗口ZSet有序且按score排序排行榜就是它的看家本领。// 点赞数1 redisTemplate.opsForZSet().incrementScore(rank:article:2025, articleId, 1); // 取Top N SetString topList redisTemplate.opsForZSet().reverseRange(rank:article:2025, 0, 9);zSet根据score自动排序reverseRange取的是分数最高的前N名排行榜接口后端几十毫秒就能返回。我还用它做限流。固定窗口限流可以用incr加expire实现滑动窗口限流则用ZSet记录每个请求时间戳的score然后统计窗口内的数量。虽然不如专门的限流组件精细但应对中小并发量的接口已经是够用的方案。4. 分布式锁这关怎么过手写SETNX方案的坑与Redisson的救场分布式锁是Java后端面试和日常实战的高频点。网上教程很多但真正实现得靠谱的没几个。我踩过好几个坑直接说结论。4.1 为什么单机synchronized扛不住多实例单机部署的Java应用用synchronized或者ReentrantLock就能锁住临界区。但一旦服务做了多实例部署、甚至容器弹性扩容A实例的锁B实例根本感知不到这时必须有一个所有实例都能访问到的公共互斥设施Redis就是最常见的选择。卖票减库存这种场景就是典型的多个实例同时操作同一份数据两个实例同时读到库存是10同时扣掉1都写回9结果库存从10变成了9而不是8。这是并发写在没有锁保护下的经典超卖问题。4.2 手写一个分布式锁会有哪些坑最简单的方案是SETNXEXPIREBoolean lock redisTemplate.opsForValue().setIfAbsent(lock:order:pay, 1, 30, TimeUnit.SECONDS); if (Boolean.TRUE.equals(lock)) { try { // 业务逻辑 } finally { redisTemplate.delete(lock:order:pay); } }看着没问题实际有至少三个坑。第一个坑锁过期时间不好定。设置30秒但业务执行超过30秒锁自动释放了第二个线程就进来了临界区被并发执行。设置300秒如果业务崩了锁一直占着所有请求被卡死300秒。这个矛盾一直存在。第二个坑释放锁时误删别人的锁。线程A的锁超时被自动释放后线程B拿到锁然后线程A执行finally里的delete把B的锁删了。这个场景一旦发生互斥保护就失效了。第三个坑原子性问题。早期版本用setnx成功后再expire分开执行一旦setnx之后服务宕机expire没执行锁永远不释放。现在单条命令set key value ex 30 nx能保证原子性但小团队自己手写很容易漏。4.3 Redisson是怎么把这些坑填掉的Redisson的RLock解决了我前面说的多数痛点。Autowired private RedissonClient redissonClient; public void pay(Order order) { RLock lock redissonClient.getLock(lock:order:pay: order.getId()); boolean locked false; try { locked lock.tryLock(5, 30, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(系统繁忙请稍后重试); } // 扣减库存、更新订单 } finally { if (locked lock.isHeldByCurrentThread()) { lock.unlock(); } } }Redisson的默认实现是获取锁成功后启动一个后台看门狗线程默认每10秒续期一次当然默认锁超时是30秒只要业务线程还活着锁就不会被提前释放。释放时lock.unlock本身就能识别当前线程持有的锁避免误删。它还支持可重入同一个线程可以多次加锁而不会把自己锁死。我在实际项目中不推荐自己造分布式锁轮子。Redisson是经过大量生产验证的成熟实现没必要为了“简单”去重复踩前人踩过的坑。只要集成redisson-spring-boot-starter以及配一个RedissonClient Bean即可。5. 缓存穿透、击穿、雪崩我的三次踩坑与对应治理思路这三个问题面试必问也是线上事故常客。我用真实踩坑的经历来讲比背八股文有用得多。5.1 缓存穿透空值缓存与布隆过滤器缓存穿透指的是请求一个根本不存在的key缓存没有数据库也没有每次请求都打到数据库上最终数据库扛不住。我第一次遇到是线上接口被人刷“不存在的商品ID”日志里看到数据库查询量异常高。排查后发现大量请求都在查一个不存在的IDRedis里当然没缓存全部打到MySQL慢查询成倍上涨。解决办法要分两层看。最直接的是把“空结果”也缓存起来比如查询结果null时缓存一个特殊占位符过期时间缩短到30秒左右至少能挡住同一ID的反复穿透。更根本的是用布隆过滤器挡在Redis前面一个ID如果不在布隆过滤器集合里直接返回不存在连Redis都不查。布隆过滤器的误判率可以设置得很低代价是少量额外内存和CPU占用。我在Spring Boot里的做法是启动时加载全量商品ID到布隆过滤器查询流程变成布隆过滤器判断存在才去查RedisRedis没有才查数据库。这套方案对固定ID集合的场景特别有效。5.2 缓存击穿一个热点key过期时大量请求同时打到数据库缓存击穿不同于穿透key是真实存在的但恰好过期了这时候瞬间有大量并发请求一起发现缓存没有集体涌向数据库。我遇到过一次热门商品的秒杀商品详情在Redis里的缓存刚好过期那一下数据库CPU直接飙满。原因就是缓存过期那一刻的并发全部穿透到了数据库。治理方案是加互斥锁。当发现缓存过期先尝试获取分布式锁只有拿到锁的线程才能去数据库回源并写缓存其余线程短暂等待后重新查缓存。这样只有一个请求打到数据库剩下的都从缓存读取。代码我在第4章写的lock.tryLock就是干这个用的。另一个思路是逻辑过期。缓存不过期只存一个带过期时间字段的对象后台定时判断是否需要刷新。这种方案在长时间高并发场景下更稳但实现复杂度高一点。5.3 缓存雪崩大量key同时过期数据库被压垮雪崩是大面积缓存同时失效比击穿的影响面大得多。最常见原因是设置了相同的过期时间比如统一把“所有商品数据”设成12小时过期。到点后几万个key同时消失查询全部回源数据库数据库直接被打穿。我现在的习惯是给每个key的过期时间加一个随机扰动比如基础TTL 24小时再加0到300秒的随机值long ttl 60 * 60 * 24 ThreadLocalRandom.current().nextLong(0, 300); redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS);这样key的过期时间就不会集中到某一个点上回源数据库的请求也会被摊平。雪崩还有一层防范服务层面做多级缓存保护比如本地堆缓存Caffeine兜底数据库层做限流降级。Redis缓存挂了还有本地缓存本地缓存挂了数据库还有连接池和慢查询保护。分层兜底思路在大型系统里至关重要。6. Docker部署Redis主从和哨兵一份可以直接套用的高可用方案单机Redis挂一次的代价很大。我在一个项目里就经历过Redis宕机后整个登录和授权功能全挂的情况。后来公司要求所有环境都上主从哨兵。Docker让这件事变得意外简单我分享一套我实际在用的部署步骤。6.1 主从复制到底复制了什么Redis主从复制是全量复制加增量复制结合从节点启动时向主节点发送同步请求主节点生成RDB快照传给从节点之后主节点把新写入的命令通过repl backlog持续同步给从节点。从节点平时只读不写可以分担读流量但写流量依然集中到主节点。主从不解决故障自动切换问题主节点宕机了需要对从节点手动提升或使用哨兵。哨兵进程会持续监控主节点发现主节点不可达时自动选一个从节点提升为新主并修改配置同时通知客户端新主地址。这套机制保证了Redis服务的高可用。6.2 Docker Compose部署主从实例我用docker-compose.yml演示生产环境建议再加认证和持久化配置version: 3.8 services: redis-master: image: redis:7.2-alpine container_name: redis-master ports: - 6379:6379 command: redis-server --appendonly yes --requirepass redis123 volumes: - redis-master-data:/data networks: - redis-net redis-slave: image: redis:7.2-alpine container_name: redis-slave ports: - 6380:6379 command: redis-server --slaveof redis-master 6379 --masterauth redis123 --appendonly yes depends_on: - redis-master volumes: - redis-slave-data:/data networks: - redis-net networks: redis-net: driver: bridge volumes: redis-master-data: redis-slave-data:启动后可以用redis-cli info replication查看主从状态看到role:master和connected_slaves:1就表示同步正常。Java客户端连接主从时关键在于读流量要往从库走写流量要往主库走。Lettuce支持ReadFrom配置比如LettuceClientConfiguration.builder() .readFrom(ReadFrom.SLAVE_PREFERRED) .build();这样一个Lettuce客户端就能完成读写分离不需要手动指定两套连接。6.3 加一个哨兵实现自动故障转移哨兵需要三个实例才能形成自动决策的集群少数服从多数。docker-compose里加三个哨兵服务配置大致如此redis-sentinel-1: image: redis:7.2-alpine container_name: redis-sentinel-1 command: redis-sentinel /etc/redis/sentinel.conf volumes: - ./sentinel1.conf:/etc/redis/sentinel.conf networks: - redis-netsentinel.conf的核心配置是sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000Java客户端里用Redis Sentinel模式连接只需要提供哨兵地址和主节点名称RedisSentinelConfiguration config new RedisSentinelConfiguration() .master(mymaster) .sentinel(127.0.0.1, 26379);这样主节点发生故障切换后客户端能自动感知新主节点地址业务无感知。我自己部署时的习惯是把持久化开启appendonly yes同时把RDB和AOF文件放到宿主机挂载出来的volume里。容器可以删了重建但数据必须留着。7. 可视化工具和日志排查日常运维别再对着命令行抓瞎很多Java开发者对redis-cli不是很熟练生产上排障效率低。我有两个习惯平时用可视化工具查看和修改数据排查问题先用INFO、SLOWLOG这类命令定位。7.1 Redis Desktop Manager与Another Redis Desktop Manager怎么选市面上最常用的两个可视化工具一个是Redis Desktop Manager简称RDM界面成熟、功能全面但对个人开放的功能有限现在免费版有一些限制。另一个是Another Redis Desktop Manager开源免费跨平台支持Windows、macOS、Linux活跃更新快我近期用得最多。它们的主要功能差别不大核心都是查看所有key、按key前缀搜索、查看String/Hash/ZSet等类型的值、执行命令行、查看INFO信息、可视化查看key的过期时间。我的操作习惯是连接配置安装目录管理登录时填上Redis密码按KEY前缀筛选避免直接全量扫描对大KEY单独在CLI面板执行类型探测命令避免界面卡死。7.2 线上排查INFO、SLOWLOG、日志文件一个都不能少Redis日志默认输出到stdoutDocker环境下看logs就能看到。如果要落盘在redis.conf里配置loglevel notice logfile /var/log/redis/redis.log生产上最常用的排查组合是INFO stats看即时QPS、连接数、内存使用情况INFO replication看主从同步状态、主节点写入量SLOWLOG GET 10看最近10条慢命令排查大KEY扫描、批量删除、超大值写入等问题INFO memory看内存碎片率、键占用量判断是否需要淘汰策略或扩容。慢查询命令是隐藏杀手。我之前遇到一个key是几兆的Hash每次hgetall都会把整个Hash拉出来响应时间要多几十毫秒高峰期直接拖累接口。后来用SLOWLOG GET抓到了这条命令再结合大KEY扫描命令找出具体key最后把大Hash拆成多个小Hash问题才解决。日常巡检我还会监控redis的连数。连接数突增往往预示代码里没走连接池、或者连接泄漏耗尽连接。在Spring Boot里配置连接池参数时我把初始连接设置成合理的基数最大连接数设置成可容忍的并发上限同时开启空闲连接回收。这个配置在Lettuce里通过配置项leValidateConnection和timeout实现简单说就是别让连接无限增长也别让连接池满了之后请求排队时间过长。8. 面试前我必刷的Redis考点数据类型、淘汰策略、持久化和一致性博主除了写代码很多时候还要当面试官。Redis在Java后端面试里是必考科目我总结了几类最常出现的问题按考察方向分成几类直接给出我认为最标准的理解。8.1 数据模型类五种类型与底层编码面试官问“Redis为什么快”除了内存和单线程我一般会补充它底层设计上的巧思String的SDS动态字符串、List的QuickList、Hash的ZipList和HashTable切换、ZSet的跳表加哈希表。跳表是ZSet最常考的点。它用多级索引加速查找平均时间复杂度O(log N)比在排序链表中逐个查找高效得多。和红黑树相比跳表实现简单、范围查询方便这也是Redis作者选它做有序集合底层的原因。8.2 持久化和淘汰策略持久化两个机制必须分清RDB是某个时间点的全量快照恢复快但可能丢最后一段数据AOF是每秒或每次都把写命令追加到日志文件数据更安全但恢复慢、日志体积大。现在Redis 7默认的混合持久化还会用RDB做全量、AOF做增量日常使用中我一般也会把两者都开启。淘汰策略是另一个高频题。我通常答几种典型场景如果缓存数据量可控且近期访问概率高用allkeys-lru很稳妥如果Redis同时存了不能丢的业务数据就选volatile-lru只对设置了过期时间的key做淘汰。绝不能允许Redis默认的noeviction在内存满时报错这在我经历的系统里发生过不止一次。8.3 分布式和一致性问题分布式锁、缓存一致性、主从切换如何保证不丢数据这三题几乎必考。分布式锁的回答要点我前面已经写过SETNX原子加过期时间加Redisson续期释放时校验线程持有。缓存一致性的标准回答是Cache Aside模式更新数据库删除缓存删除失败要用重试机制最终一致。值得强调的是纯净答案容易背实际业务的坑在于删除失败怎么处理。我现在的做法是把删除操作同步执行删除失败则放入延迟队列由一个后台任务稍后重试同时做好监控告警。这样即使瞬时网络抖动缓存也不会长期脏读。面试时如果能带上这些真实的“踩坑案例”跟背八股文的差别一下就拉开了。很多候选人把Redis用得炉火纯青但一轮到“线上出过什么问题、怎么定位、怎么修复”就开始支支吾吾。我始终觉得实践到位的人谈起这些细节眼神是藏不住的。日常在项目里花半小时看看INFO、SLOWLOG远比刷一百道面试题更有说服力。