1. 为什么Java项目里操作Redis很多老手第一句话都是“别用客户端当数据库”先说个场景。某天你接手一个Java服务发现里面用Redis存用户会话代码里到处是set、get再仔细一看居然还有人把订单详情整个序列化塞进去过期时间设成了一天。线上一压测Redis内存直接飙到几个GCPU也时常报警。这时候你就明白Redis在Java项目里被用歪了比不会用更可怕。这个标题覆盖的范围其实挺宽泛的从Java原生客户端到Spring Data Redis到Spring Boot自动配置内容能写一本书。但大多数人真正的痛点其实是那几个怎么连、怎么封装、怎么避免Key过期和内存浪费、怎么在Spring环境里少写重复代码。所以我这篇不是讲API手册而是从一个实际项目折腾的角度把“在Java里操作Redis”这条链路捋清楚包括选型理由、核心API使用逻辑、Spring环境下的封装差异还有一堆我在真实环境里踩过的坑。适合谁看刚接触Redis不久、想搞明白Java里到底用Jedis还是Lettuce的初学者以及在Spring Boot项目里用过Redis但总感觉配置没吃透、序列化总是乱码、管道和事务不敢用的中级开发者。文章里的代码都是Java 8 以上可跑Spring Boot 用 2.x 和 3.x 都兼容关键依赖和配置我会写清楚。先交代一个我自己的基本盘我平时项目里Redis的主要用途是缓存热点数据、分布式锁、接口幂等、排行榜和简单的消息队列基本不碰那些特别重的模块。下面所有经验都围绕这几个场景展开针对性足够强也不至于把范围扯得太散。2. 动手之前先认清三件事Redis版本、Java客户端选型、连接池参数2.1 版本差异容易让你“照着教程写却连不上”Redis服务端版本和Java客户端的兼容性很多人不重视直到线上出问题才回头查。这里的最基本事实是Redis 6.0 之前默认不支持ACLRedis 6.0之后引入了ACL和更细粒度的权限控制RESP协议从Redis 6.0开始支持RESP3但绝大多数Java客户端默认还是用RESP2协议通信。实操中我建议直接用Redis 6.x或7.x原因不复杂ACL能力在做多环境隔离时很有用而且新版对内存淘汰策略的文档和工具链支持更完整。如果你还在用Redis 5.x也不是不能跑但别用那些只有新版本才支持的指令比如SET命令的GET选项在旧版上表现不一致。客户端版本也同理。Jedis 4.x和Lettuce 6.x很多API名字都没变但连接池参数、超时时间单位、异常类型做了调整。你拿网上三年前的教程配上最新客户端很容易出现redis.clients.jedis.exceptions.JedisConnectionException这类报错排查半天发现只是参数名变了。2.2 Jedis还是Lettuce这不是二选一是看场景Java生态里最主流的两个客户端就是Jedis和Lettuce。都到2025年了还是有人把这两个对立起来实际用起来各有各的脾气。Jedis的特点是直接、粗暴、贴近原生命令。它的Jedis对象就是一次连接的封装连完就关或者从连接池借出来用完归还。优点是API和你敲Redis命令的感觉完全一致jedis.set(key, value)、jedis.expire(key, seconds)没有任何中间层排查问题非常直观。缺点是它本身是阻塞式IO每个命令都要独占连接高并发下必须依赖连接池不然连接数一多就扛不住。Lettuce的特点是异步、响应式、基于Netty。它底层是连接复用的多个线程可以共享同一组连接靠异步IO和多路复用撑高并发。所以在Spring Boot 2.x之后Spring官方把默认客户端从Jedis换成了Lettuce很大程度上就是看中它的连接利用率和性能上限。我个人的选型建议很简单场景推荐快速原型、临时脚本、要快速看效果JedisSpring Boot项目、高并发读写、连接资源敏感Lettuce需要异步/响应式APILettuce需要原生命令逐一对照、调试方便Jedis关于Lettuce的线程安全问题我一直以来的结论是Lettuce的RedisConnection是线程安全的但如果你用了connect()显式获取连接再手动收放那还是要注意别共享同一个连接做长时间阻塞操作。Spring封装好的StringRedisTemplate和RedisTemplate本身是线程安全的放心用。2.3 连接池参数别照着默认抄四个参数必须自己调很多人在Spring Boot里配置Redis连接池时就写个max-total8然后就跑起来了。这个默认值来自通用连接池的保守设定放到Redis场景经常不够用。我自己的经验值供参考spring: redis: host: 127.0.0.1 port: 6379 password: yourpassword # 没有密码就不写 database: 0 # 默认0库多环境隔离建议分开 timeout: 3000ms lettuce: pool: max-active: 32 # 最大连接数 max-idle: 16 # 最大空闲连接 min-idle: 4 # 最小空闲连接 max-wait: 3000ms # 获取连接超时 shutdown-timeout: 100msmax-active为什么是32而不是8因为Lettuce虽然是连接复用但Spring封装后仍然会为阻塞操作、事务、管道等场景申请额外连接。8太小高并发时后面请求全在等连接32是个相对均衡的值常规业务足够又不至于浪费文件描述符。max-wait尤其重要。线上出现过一窝蜂超时的情况就是因为某个慢查询把连接池占满后续所有请求在max-wait内没等到连接直接报RedisConnectionFailureException。把max-wait设成3000ms再配合监控连接池使用率能尽早发现问题。database这个配置项我建议每个环境独占一个库位比如dev用0、test用1、prod用2。这样做的好处是环境隔离清晰清数据方便误操作影响面可控。注意Redis的库是逻辑库不是物理隔离性能上没什么本质差别。3. 原生客户端实操从Jedis直连到Lettuce异步把命令搬到Java里3.1 Jedis入门连接、设值、过期时间的三件套先用一个最简单的Maven依赖搞定Jedisdependency groupIdredis.clients/groupId artifactIdjedis/artifactId version4.4.3/version /dependency连接方式有两种直连和连接池。小工具、测试代码、一次性脚本用直连没毛病生产环境必须上连接池。别贪图方便直连Redis连接建立是有开销的高并发下每次新建连接都在消耗TCP握手和内存。// 直连方式 Jedis jedis new Jedis(127.0.0.1, 6379); jedis.auth(yourpassword); // 有密码才需要 jedis.set(name, zhang3); jedis.expire(name, 60); System.out.println(jedis.get(name)); jedis.close();连接池方式JedisPoolConfig config new JedisPoolConfig(); config.setMaxTotal(32); config.setMaxIdle(16); config.setMinIdle(4); config.setMaxWaitMillis(3000); JedisPool pool new JedisPool(config, 127.0.0.1, 6379, 3000, yourpassword); try (Jedis jedis pool.getResource()) { String result jedis.set(name, zhang3, NX, EX, 60); // 返回OK说明设置成功返回null说明Key已存在 }这里的set(name, zhang3, NX, EX, 60)就是分布式锁最常用的原子写法同时满足“不存在才设置”和“设置过期时间”避免先setnx再expire两步操作带来的非原子风险。Jedis的API基本就是Redis命令的镜像hset、rpush、zadd这些都能直接调。遇到冷门命令也不用慌jedis.sendCommand()能搞定绝大多数。3.2 Lettuce连接复用和异步API的细节Lettuce的依赖dependency groupIdio.lettuce/groupId artifactIdlettuce-core/artifactId version6.3.0.RELEASE/version /dependency基本连接方式RedisClient client RedisClient.create(redis://password127.0.0.1:6379/0); StatefulRedisConnectionString, String connection client.connect(); RedisStringCommandsString, String commands connection.sync(); commands.set(name, zhang3); System.out.println(commands.get(name)); connection.close(); client.shutdown();Lettuce最吸引人的异步能力体现在async()和reactive()两套API上。异步用的是CompletableFuture配合Java 8的链式调用很舒服RedisAsyncCommandsString, String async connection.async(); async.set(name, zhang3).thenAccept(result - { System.out.println(异步写入结果: result); });有一点要注意异步结果不是立即返回的别在thenAccept里写那种会阻塞的操作否则异步的优势就没了。还有异步命令在连接关闭时会收到异常批量提交的任务如果中间某个失败后续任务是继续执行还是整体回滚取决于你用的是不是事务包裹。Lettuce底层靠Netty做多路复用所以很多命令可以被同一个连接并发处理。这跟Jedis每个请求独占一条连接完全不同。这也是为什么Spring默认选Lettuce的原因——连接数需求低系统资源占用小吞吐量上限高。3.3 管道Pipeline和事务Transaction一次往返解决N个命令这俩经常被放在一起说但适用场景完全不同。管道的核心是减少网络往返时间RTT把一批命令打包发送服务端依次执行中间不等待每个命令的响应最后一次性返回结果。事务的核心是保证这批命令要么都执行要么都不执行。管道适合批量写入、批量查询比如初始化一批用户缓存、批量设置排行榜初始分。Jedis里用pipelinetry (Jedis jedis pool.getResource()) { Pipeline pipeline jedis.pipelined(); for (int i 0; i 1000; i) { pipeline.set(user: i, value: i); pipeline.expire(user: i, 3600); } // 提交并返回所有结果 ListObject results pipeline.syncAndReturnAll(); }注意syncAndReturnAll()返回的结果列表顺序和命令提交顺序是一致的。如果只调用sync()则只负责发送不关心结果性能稍好一点。我建议能拿结果就拿因为测试监控时需要确认实际成功数。事务在Java里的写法通常是multi、exec两条命令包起来try (Jedis jedis pool.getResource()) { Transaction tx jedis.multi(); tx.set(key1, value1); tx.incr(counter); ListObject results tx.exec(); }事务期间Redis服务端会把命令排队exec时统一执行。我要强调一点Redis事务不支持回滚它只保证“命令全部执行”如果中间某条命令语法错误其他命令照样执行。所以在Java侧做好参数校验别指望Redis帮你回滚。这也是很多老手宁愿用Lua脚本的原因Lua能保证多条命令的原子性而且执行期间不会被其他客户端命令插入逻辑控制也更强。3.4 Lua脚本原子性的终极方案在Java里执行Lua脚本Jedis的写法String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; try (Jedis jedis pool.getResource()) { Object result jedis.eval(luaScript, Collections.singletonList(lock:order:123), Collections.singletonList(uuid-token)); // 返回1说明删除成功0说明value不匹配不删 }这段Lua是分布式锁释放的标准写法先比对当前值是不是自己设置的唯一标识是才删除避免误删别人的锁。用Java原生命令组合也行但至少两次网络交互无法保证原子性用Lua一次搞定永远不会有中间状态。Lettuce里不光能evalSpring Data Redis的DefaultRedisScript封得更舒服这个放到下一章节再说。4. Spring Data Redis封装之后三种Template的区别和用法必须吃透4.1 StringRedisTemplate、RedisTemplate、ReactiveRedisTemplate怎么选进入Spring环境之后你基本不会直接跟Jedis或Lettuce打交道了操作全部经由RedisTemplate及其变体。StringRedisTemplate是Spring Boot自动配置里最推荐日常使用的。它的key和value的序列化方式默认都是StringRedisSerializer也就是存进去什么字符串存到Redis里就是什么字符串人类可读排查问题直接redis-cli get就能看到。适合所有key和value都是字符串的场景比如缓存JSON字符串、计数器、验证码。RedisTemplate是更通用的模板默认用的是JdkSerializationRedisSerializer。这个序列化器会把你存入的对象转成Java序列化二进制可读性为零还会把类信息写进去key看起来像\xac\xed\x00\x05t\x00\x03foo这种。好处是能直接存任意对象坏处是存储体积大、跨语言不友好。我的建议是别用默认的RedisTemplate要么换成JSON序列化器要么直接用StringRedisTemplate加手动序列化。ReactiveRedisTemplate是响应式编程专属API返回Mono和Flux适合WebFlux项目。如果你用的是Spring MVC传统模型没必要硬上这个学习和排查成本都不低。4.2 RedisTemplate的序列化器配置五选一不如就选两种Spring Boot里RedisTemplate序列化器的可选项看着多String、Jackson、Jdk、GenericJackson、Jackson2Json。实际上日常项目里够用的就两种全String或者key用String、value用Jackson。我自己项目的配置这么写的Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // key序列化 StringRedisSerializer stringSerializer new StringRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); // value序列化 GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }这样配置之后key在Redis里可读value是JSON格式跨语言调试也没问题。GenericJackson2JsonRedisSerializer会在序列化时带上class字段反序列化时能还原成原来的对象类型。注意如果不想存类型信息用Jackson2JsonRedisSerializer并手动指定目标类型省出来的存储空间很可观但对泛型和多态支持弱一些。提示无论选哪种序列化器改了配置之后一定先做一次读写验证。因为老数据是按旧序列化器写的换序列化器后读老key会直接反序列化失败线上切换前做好数据迁移或灰度方案。4.3 操作Hash、List、ZSet时的类型坑用RedisTemplate操作Hash类型时最典型的坑是Hash里的字段序列化器没设置。你如果只设置了key和value的序列化器没设置hashKeySerializer和hashValueSerializer默认就落到Jdk序列化存进去又是乱码。// 正确姿势 stringRedisTemplate.opsForHash().put(user:100, name, zhang3); stringRedisTemplate.opsForHash().put(user:100, age, 25); MapObject, Object entries stringRedisTemplate.opsForHash().entries(user:100);StringRedisTemplate下Hash的字段名是String存进去可读。但用RedisTemplate时如果忘了配Hash序列化器字段名name会被序列化成二进制乱码查问题时非常崩溃。ZSet的score字段是double类型操作排行榜时一般没问题但要注意浮点精度。比如zdd添加成员的score如果是99.99Redis内部存的是双精度浮点多次累加可能出现99.989999999的情况。做排行榜展示时建议前端拿到分数后做格式化不要直接展示原始值。List类型方面leftPush和rightPush的方向决定了你用List当栈还是当队列。拿List当消息队列用的时候注意消费端用rightPop并且加超时阻塞比如rightPop(key, timeout)这样能在没有消息时避免空轮询。5. Spring Boot环境下的自动配置与自定义扩展把Redis用顺手5.1 自动配置都帮你干了什么Spring Boot的RedisAutoConfiguration会自动创建RedisConnectionFactory、StringRedisTemplate和RedisTemplate。你只要引入依赖并配置连接信息就能直接注入使用。自动配置的RedisTemplate默认是RedisTemplateObject, Objectvalue序列化器默认是Jdk。你已经猜到问题了吧——直接用自动配置的RedisTemplate存入的key是乱码。所以几乎每个项目都要覆盖这个Bean用一个自己配置的泛型更明确的RedisTemplateString, Object替换默认的。上面的RedisConfig配置类就是做这件事。自定义Bean覆盖自动配置的规则很简单在配置类里声明同类型BeanSpring Boot会以自定义Bean优先。但注意Bean方法名最好别叫redisTemplate叫redisTemplate是故意覆盖叫myRedisTemplate则保留了默认的两者共存容易让人分不清注入的是哪个。我建议直接覆盖并取名为redisTemplate让所有注入点都拿到自定义的那个。5.2 自己封装一个RedisService别让业务代码散落一堆opsForXxx上面那些Template的API用归用但业务代码里到处opsForValue()、opsForHash()其实非常割裂。我习惯再包一层RedisService把常用的操作统一收口顺便加上重试、空值处理、过期策略。一个精简版的封装思路Service public class RedisService { private final StringRedisTemplate stringRedisTemplate; public RedisService(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate stringRedisTemplate; } public void set(String key, String value, long timeout, TimeUnit unit) { stringRedisTemplate.opsForValue().set(key, value, timeout, unit); } public String get(String key) { return stringRedisTemplate.opsForValue().get(key); } public boolean setIfAbsent(String key, String value, long timeout, TimeUnit unit) { return stringRedisTemplate.opsForValue().setIfAbsent(key, value, timeout, unit); } public void delete(String key) { stringRedisTemplate.delete(key); } public Long increment(String key, long delta) { return stringRedisTemplate.opsForValue().increment(key, delta); } }这个封装最大的价值不是把API变少而是把“缓存的读写策略”收敛到了一处。比如你决定所有缓存key统一加业务前缀、统一设置默认过期时间、统一处理值为空的情况只需要改这个类就够了业务代码一行都不用动。5.3 缓存穿透、击穿、雪崩的典型解法直接放进Service层这三个是Java后端聊缓存绕不开的话题我把它们跟RedisService放到一起讲因为真正落地就在这个封装层。缓存穿透是指查询一个不存在的key缓存和数据库都没有每次请求都打到数据库。常规解法是缓存空值但空值也要注意过期时间别太长设个2到5分钟就够。也可以在Service层的get方法里约定如果查出来是空字符串或特殊占位符就视为数据库不存在不再放行到DB查询。缓存击穿是指某个热点key过期瞬间大量并发请求同时打到DB。解法是互斥锁重建缓存或者提前把热点key的过期时间拉长并异步刷新。互斥锁在Service层就能实现用setIfAbsent当锁public String getWithMutex(String key, long expireTime, TimeUnit unit) { String value stringRedisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 尝试获取锁lockKey用业务key加后缀value用唯一请求标识 String lockKey key :lock; String requestId UUID.randomUUID().toString(); boolean locked setIfAbsent(lockKey, requestId, expireTime, unit); if (!locked) { // 没拿到锁短暂sleep后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getWithMutex(key, expireTime, unit); } try { value loadFromDb(key); // 真正查DB stringRedisTemplate.opsForValue().set(key, value, expireTime, unit); return value; } finally { // 释放锁时校验requestId String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong script new DefaultRedisScript(luaScript, Long.class); stringRedisTemplate.execute(script, Collections.singletonList(lockKey), requestId); } }这个方案牺牲了一点性能拿不到锁的请求要等待但把DB压力控制住了。注意释放锁时用了Lua脚本校验requestId避免因为处理超时把别人刚获取的锁误删。缓存雪崩是指大量key同时过期或者Redis实例宕机导致所有请求打到DB。对策分散key过期时间加随机值、多级缓存、Redis主从加哨兵。在Service层一步步来先把过期时间的随机抖动做上能避免大部分刷屏式击穿。6. 分布式锁的实现细节与Lua脚本落地6.1 为什么不用setnx加expire这个老坑到现在还有人踩很多人一开始学分布式锁都写过这种代码// 错误示范 Boolean set stringRedisTemplate.opsForValue().setIfAbsent(lock, value); if (set) { stringRedisTemplate.expire(lock, 30, TimeUnit.SECONDS); // 业务逻辑 stringRedisTemplate.delete(lock); }问题在于setIfAbsent和expire是两条命令。如果第一条执行成功、第二条还没执行时进程崩溃或网络断开这个锁就没有过期时间直接变成死锁。为什么每次讲Redis分布式锁都要强调这个因为线上确实有人这么写锁永远不会释放直到人工干预。正确做法是把setIfAbsent和过期时间合并成一条原子命令stringRedisTemplate.opsForValue().setIfAbsent(lock:order:123, requestId, 30, TimeUnit.SECONDS);Spring Data Redis里的setIfAbsent(K key, V value, long timeout, TimeUnit unit)就是原子操作底层走的就是SET key value NX EX timeout一次网络请求搞定。6.2 锁的过期时间怎么定续期怎么做锁的过期时间设太短业务还没执行完锁就没了设太长万一持有锁的节点挂了其他节点要等很久。折中方案是看业务耗时设置比如业务平均耗时200ms锁过期时间设5秒已经留了20多倍余量。但总有极端情况比如慢GC、IO阻塞导致业务执行超过锁过期时间。这种情况我推荐用续期机制。最简单的续期是起一个守护线程每隔三分之一过期时间检查一次如果业务还没结束就执行expire续期。业界有现成的Redisson的watch dog就是这个逻辑默认30秒过期每10秒续一次。自己实现续期也不复杂ScheduledExecutorService executor Executors.newScheduledThreadPool(1); ScheduledFuture? renewTask executor.scheduleAtFixedRate(() - { stringRedisTemplate.expire(lockKey, expireTime, TimeUnit.SECONDS); }, 10, 10, TimeUnit.SECONDS);关键点在于续期任务一定要在finally里cancel掉否则锁释放了线程还在继续续一个不存在的key白白增加Redis压力。而且线程池建议做成静态共享不要每个锁操作都new一个。6.3 Redisson的RLock到底比自研强在哪如果有人问我分布式锁到底自己写还是直接用Redisson我的答案是中小项目可以自己写但涉及高并发、需要可重入、需要等待锁、需要公平锁的场景直接用Redisson。Redisson的RLock天然支持可重入同一个线程可以多次加锁不会死锁支持tryLock(waitTime, leaseTime, TimeUnit)拿不到锁时等待指定时间而不是直接返回失败底层续期逻辑已经内置不用自己写守护线程。RLock lock redissonClient.getLock(lock:order:123); boolean locked lock.tryLock(3, 30, TimeUnit.SECONDS); if (locked) { try { // 业务逻辑 } finally { lock.unlock(); } }注意tryLock第一个参数是等待时间第二个是锁自动释放时间。如果传了leaseTimeRedisson不会开启续期如果不传默认会启动watch dog续期。用unlock()释放锁时Redisson内部也会做身份校验比手写Lua省心。7. 序列化方案的完整对比以及我对乱码问题的最终解法7.1 从乱码现场反推序列化器配置“存进去明明是字符串查出来变成\xac\xed开头的一串”这个问题在Spring Boot Redis项目里出现的频率超高。根因只有一个key或value的序列化器用成了Jdk。\xac\xed是Java序列化魔法头\x00\x05是版本号看到这个就说明当前读写用的序列化器和当初写入时的序列化器不一致。排查链路一般是这样的第一步redis-cli登录Redis用type key看类型用get key看值。如果值是人类可读的字符串说明写入端用的是String序列化。如果值是一串带\xac\xed开头的二进制说明写入端用了Jdk序列化。第二步回代码里看当前读取用的Template是哪一种。如果注入的是RedisTemplateObject, Object且没自定义序列化器那你读的时候默认就是Jdk去反序列化Jdk格式的数据如果写入端是String格式必然失败或者乱码。第三步统一改配置。全项目只保留StringRedisTemplate和自定义的RedisTemplateString, Object所有key强制String序列化。这是最不容易出错的组合。7.2 对象缓存怎么存JSON字符串还是JDK序列化对象对象缓存的存储格式选择直接决定后续的调试体验和跨语言支持程度。我的建议是存JSON字符串理由有三个可读redis-cli直接能看内容跨语言Java写、Python读、Node读都行只要JSON结构对灵活字段增减只影响读取端解析不必强制所有实例都升级。具体操作思路业务对象先转JSON再存入StringRedisTemplate读取时取出JSON字符串再用ObjectMapper或Gson转回对象。你可以把这段逻辑封装成两个工具方法比如setJson(key, obj, expireTime)和getJson(key, clazz)。如果确实要用RedisTemplate直接存对象序列化器就用GenericJackson2JsonRedisSerializer。但有一点要记住反序列化时GenericJackson2JsonRedisSerializer依赖对象有默认构造函数如果对象没有无参构造器反序列化直接报错。这个坑很隐蔽建议所有缓存对象都保留一个无参构造方法。7.3 序列化器选型对照表序列化器key可读性value可读性跨语言存储体积推荐场景StringRedisSerializer完全可读完全可读好小key和value都是字符串JdkSerializationRedisSerializer乱码乱码差大基本不推荐GenericJackson2JsonRedisSerializer可读JSON可读好中存对象且要保留类型信息Jackson2JsonRedisSerializer可读JSON可读好小存对象明确类型Kryo第三方不可读不可读一般极小追求极致存储压缩不在意可读性在线下跟我合作过的一个项目组为了省内存把用户缓存对象用了Kryo序列化结果联调时前端同学要查缓存内容redis-cli完全看不出来里面是什么。后来还是换回GenericJackson。我的态度是除非内存紧张到需要省那几十个字节否则别为压缩牺牲可读性。8. 实际项目里Redis操作最容易翻车的五个场景8.1 慢查询大Key和批量操作引发的Redis阻塞Redis是单线程执行命令一个慢命令会让后续所有命令排队等待临床表现就是“某个时刻所有接口突然变慢”。最常见的慢命令是KEYS、SMEMBERS、HGETALL尤其是大Key。KEYS pattern为什么危险它需要遍历整个键空间数据量大时直接阻塞Redis。生产环境禁用要查Key用SCANScanOptions options ScanOptions.scanOptions().match(user:*).count(100).build(); CursorString cursor stringRedisTemplate.scan(options); while (cursor.hasNext()) { String key cursor.next(); // 处理key } cursor.close();HGETALL对大Hash也一样几千个字段一次性全部返回序列化和网络传输都要时间。优化方式是拆Hash把大Hash按业务维度拆成多个小Hash或者用HSCAN分批取。千万级别的数据慢查询一旦出现从日志里看命令耗时几百毫秒整个Redis实例的影响面非常大。8.2 大Value为什么单个Value超过10KB要警惕单个Value过大除了拖慢网络传输还容易引发内存碎片化和持久化开销。Redis做RDB快照时会fork子进程大Key导致内存页表复制量变大复制期间Redis阻塞时间变长。我的建议常规缓存Value控制在10KB以内。如果业务确实需要存大于100KB的JSON优先考虑拆分存储、压缩存储或者换到专门的存储系统。也别迷信压缩压缩CPU开销不低查询频率高的场景得不偿失。8.3 Key命名规范冒号分隔比纯拼接更值得推广Redis的Key命名业界通用的建议是业务:实体:ID的冒号分隔法比如user:profile:10086、order:status:20250101001。好处有三条可读性强一眼看出业务归属支持SCAN按前缀匹配便于在Redis Desktop Manager这类工具里按前缀浏览分组。反面教材是把所有Key揉成一个无意义的长字符串比如userprofile10086或者userId10086Date20250101。这种Key没法按业务归类维护时为了找一个Key只能全量扫非常痛苦。8.4 过期策略不统一有的Key永不过期有的刚写就过期Teammates写缓存的时候最随意的地方就是过期时间。同一个接口的缓存有人设1小时有人设5分钟还有人压根不设。线上内存增长快往往就是一堆没有过期时间的“永久Key”堆出来的。我的做法是定义公共常量类public class CacheTime { public static final long GENERAL 30L; // 30秒 public static final long SHORT 5L; // 5分钟 public static final long MIDDLE 30L; // 30分钟 public static final long LONG 24L * 60; // 1天 }所有地方引用常量不同业务按实际频率选档位。这样既能避免“刚写就过期”也能避免“永久不删”。同时定期用命令统计没有TTL的Key比如redis-cli里可以用scan结合ttl检查发现业务上不该永久的Key及时补上过期时间。8.5 连接泄漏用完的连接没还回去无论是Jedis还是Lettuce连接资源必须规范收放。Jedis如果用了连接池try-with-resources或finally里调用close()close()不是物理断开而是归还连接池。忘了调用池里的连接慢慢被借光后面请求全部超时。Lettuce的StatefulRedisConnection也要在应用关闭时调用close()。Spring环境下用RedisTemplate一般不用担心Spring容器会管理连接工厂生命周期但如果你在工具类里手动connect()就要自己负责关闭。提示每次改动Redis连接相关的代码后看两个指标一是Redis实例的connected_clients正常波动平稳二是Java进程的TCP连接数如果在缓慢上升大概率有连接没释放。9. 多环境配置与Redis运行状态监控最后聊点能落地的9.1 多环境配置的差异化管理开发、测试、生产的Redis参数通常不一样。开发环境可以不用密码生产必须加密码并且建议开启ACL做最小权限授权。Spring Boot多环境配置用配置文件区分即可# application-dev.yml spring: redis: host: localhost port: 6379 database: 0# application-prod.yml spring: redis: host: redis-prod.internal port: 6379 password: ${REDIS_PASSWORD} # 密码放环境变量里 database: 2 lettuce: pool: max-active: 64密码写在配置文件里有个风险配置文件一旦泄露所有环境Redis密码全部暴露。我建议密码全部从环境变量或配置中心读取本地开发可以通过.env文件注入生产从部署平台的环境变量注入。9.2 INFO命令能告诉你的六个关键信息排查Redis性能问题我最先用的命令是INFO。里面有几个指标价值非常高connected_clients当前连接数异常升高说明应用侧可能连接泄漏或者并发突发。used_memory和used_memory_rss前者是逻辑内存后者是实际占用物理内存两者差距过大多半是内存碎片。keyspace_hits和keyspace_misses缓存命中率命中率骤降说明缓存大量失效或者业务key改造。evicted_keys内存淘汰的key数量激增说明内存不够了或者过期时间设置不合理。latest_fork_usec上次RDB快照fork耗时数值超过几秒说明大Key问题严重。instantaneous_ops_per_sec当前QPS初步判断实例负载。Java项目里可以用RedisTemplate的execute拿到连接后执行info或者直接集成Spring Boot Actuator的Redis健康检查。日常最方便的还是在Redis命令行工具里redis-cli info一条条看或者接上监控面板自动采集。9.3 压测时Redis连接数为什么突然暴涨怎么定位某个下午A同学跑完一轮压测发现Redis的connected_clients从几十涨到了几千。第一反应是“是不是连接池没关”打开代码一看连接池配置都正常。再看日志发现每个请求都在从连接池获取连接后没有释放。还有一个经常被忽略的点如果使用了LettuceSpring Data Redis在异步操作时可能会额外创建连接这些连接如果没有被复用池管理数量会随并发线性增长。解决办法是确认spring.redis.lettuce.pool参数生效同时限制异步并发数必要时把异步操作改成同步阻塞压测数据会更可预期。定位这一类问题我的排查顺序是先看当前活跃连接数再对Java进程做线程dump找到“拿着Redis连接不放”的线程栈最后对照代码定位遗漏close()的逻辑。线程dump这一步最有效尤其能定位客户端连接泄漏。10. 最后分享一个我习惯的实践顺序从零开始在一个Spring Boot项目里接入Redis我建议按这个顺序走先在本地跑通Jedis直连确认对Redis命令本身的操作没问题再把Jedis换成Lettuce感受连接复用的写法和异步API接着引入Spring Data Redis用StringRedisTemplate完成基本读写覆盖默认序列化器然后把对象缓存和分布式锁纳入自封装的RedisService最后统一配置多环境参数、监控指标和压测验证。这套顺序是我自己踩了很多次坑之后顺出来的它能保证每一步的变量只有几个出了问题容易定位。如果你预算有限只做三个动作那我建议是序列化器全部换成String或JSON、连接池参数按业务调过、分布式锁用原子命令加Lua释放。这三样做了项目里Redis的稳定性就已经超过大部分“能跑就行”的系统了。iPad按键声音关闭的技巧如何通过快捷设置与辅助功能实现静音操作 嘿各位数码控和iPad重度用户今天咱们来聊聊一个看似不起眼实操起来却能让幸福感直线上升的小功能——关闭iPad的按键声音。如果你跟我一样喜欢在深夜窝在被窝里刷剧、打游戏、翻网页那每次敲击屏幕发出的“嗒嗒”声简直就像在安静的图书馆里大声嚼薯片不仅自己觉得吵还容易打扰到身边人。先别急着划走这篇文章不只是教你怎么关掉那个键盘打字声而是会从快捷设置、系统设置到辅助功能把iPad上所有跟“按键声音”相关的开关一次性给你捋清楚包括哪些机型支持、哪些设置之间会互相影响、以及几种实际场景下的最优解。