1. 为什么我坚持自己封装一个RedisUtils而不是直接用Spring Data Redis先说个面试场景。很多候选人简历上都写着“熟悉Redis”结果我问到“你们项目里的Redis工具类是怎么封装的”十有八九会愣一下然后告诉我“我们直接用的RedisTemplate”。这个回答倒也不算错但你要是做过三五个中型以上项目就会发现直接拿RedisTemplate裸奔代码里会躺满一堆重复的、容易踩坑的样板代码。比如key拼接、序列化配置、分布式锁的实现、缓存的空值处理这些逻辑散落在service层各处改一个序列化方案可能要动几百处调用。我自己在项目里维护了一套RedisUtils工具类沉淀了好几年踩过不少坑也重构过好几轮。这篇文章把这套东西的核心设计思路和完整实现拆开讲清楚包括为什么有些地方要这么写、哪些做法看起来正确但实际会埋雷、以及在并发场景下怎么保证不翻车。如果你是刚接触Java后端、想理解Redis工具类到底该怎么封装的同学或者已经写了一阵子Redis但总觉得代码别扭的同行这篇文章应该能给你一些可落地的参考。先说清楚这套工具类的定位它不是要替代RedisTemplate而是在RedisTemplate之上做一层薄封装解决三个最痛的问题规范key的生成和管理避免散落各处的手写字符串拼接统一序列化策略防止LocalDateTime、空对象这类东西在存取时搞出幺蛾子把分布式锁、限流、幂等等高频场景封装成一行调用降低使用成本2. 工具类设计的核心思路与整体结构2.1 先想清楚这层封装到底放在哪一层很多项目里你会看到这样的调用方式service层直接用stringRedisTemplate.opsForValue().set(key, value)然后一堆魔法字符串散落在业务代码里。这其实不叫封装这叫绕过了封装。我的思路是不管底层你是谁service层永远只跟RedisUtils互动。这样底层无论从Jedis换成Lettuce还是从StringRedisTemplate换成自定义序列化的RedisTemplate对上层业务都是无感的。整个结构分三层接口层对外暴露的方法比如set、get、delete、expire、lock语义要清楚。核心实现层基于StringRedisTemplate完成具体操作处理序列化、解析、重试这些脏活累活。底层配置层负责创建RedisTemplate的bean、设置序列化器、配置连接工厂。2.2 序列化策略的选择决定了你会不会半夜被叫起来这是整个工具类里最容易出幺蛾子的地方。默认的JdkSerializationRedisSerializer会把对象序列化成一堆二进制字节存在Redis里的key会带一串乱码前缀\xAC\xED\x00\x05t\x00你在命令行里根本没法直观排查数据。而且一旦实体类结构变更了反序列化版本号老的缓存数据就全废了。我最终采用的是StringRedisTemplate 手动JSON序列化的方式。也就是说往Redis里放对象的时候提前把它转成JSON字符串取出来的时候反序列化成目标类型。这种方式牺牲了一点点自动化的便利性但换来的是缓存数据直读、跨语言可解析、升级兼容性好。实际项目中我用的是Jackson来做序列化尽量不用Fastjson一方面是维护活跃度的问题另一方面Jackson对复杂泛型和Java时间类型的支持更规范一些。序列化的核心配置我放在一个单独的RedisConfig类里大致是这么写的Configuration public class RedisConfig { Bean public RedisTemplateString, String redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, String template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashKeySerializer(stringSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }注意这里value序列化器用的是GenericJackson2JsonRedisSerializer而不是Jackson2JsonRedisSerializer。后者的默认构造不会带上类型信息反序列化的时候拿到手的是LinkedHashMap你强转成自定义对象就报ClassCastException。这个坑我至少见过三个同事踩过。2.3 命名规范key跟前缀后缀的设计逻辑key的设计直接关系到线上问题排查的效率。我推荐这样的规范业务模块:业务实体:唯一标识:字段比如用户信息的key就是user:info:1001订单列表的分页缓存就是order:page:1001:1:20。在工具类里我会内置一个方法把模块名和业务标识拼接起来统一加上系统级前缀避免多个服务共用同一个Redis实例时key冲突private static final String GLOBAL_PREFIX myapp:; private String buildKey(String module, String key) { return GLOBAL_PREFIX module : key; }这样做的好处是在Redis Desktop Manager或者命令行里按myapp:user:*就能一眼看到某个模块的全部缓存。不要小看这个设计等缓存数据量上来了定位问题时这个前缀就是救命稻草。3. 核心功能实现与实操细节3.1 缓存的存取set与get完整实现工具类最基础的操作就是存字符串和对象。字符串直接存对象转JSON存。这里的重点在于过期时间的单位统一。很多人用着用着就搞混秒和毫秒我干脆统一对外暴露的接口都用Duration或者秒内部再转换public static void set(String key, Object value, Duration timeout) { String jsonValue serialize(value); redisTemplate.opsForValue().set(key, jsonValue, timeout); } public static T T get(String key, ClassT clazz) { String jsonValue redisTemplate.opsForValue().get(key); if (jsonValue null) { return null; } return deserialize(jsonValue, clazz); }序列化和反序列化我单独的私有方法处理序列化时做个判空避免包装成JSON字符串的时候把null也变成一个字符串null存进去导致缓存穿透判断失效。还有一个细节get的时候要区分“key不存在”和“key存在但是值为空”。这在后面处理缓存穿透时非常关键。3.2 分布式锁的正确姿势分布式锁是工具类里的重头戏。如果你只是用setnx加锁、用del解锁那大概率会在高并发下出问题线程A的锁还没释放就超时了线程B拿到锁开始执行线程A执行完后把B的锁给删了直接锁失效。有人会说用Redisson确实Redisson的看门狗机制解决了很多问题。但如果你不想引入额外的依赖直接用Redis原生命令也能写出还算靠谱的锁。核心就是两点一是加锁时要带上唯一标识二是解锁时要校验该标识。我在工具类里封装了lock和unlockpublic static boolean lock(String lockKey, String requestId, long expireSeconds) { String key buildKey(lock, lockKey); return redisTemplate.opsForValue().setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public static void unlock(String lockKey, String requestId) { String key buildKey(lock, lockKey); String value redisTemplate.opsForValue().get(key); if (requestId.equals(value)) { redisTemplate.delete(key); } }看到没有requestId就是那个唯一标识可以用UUID生成也可以用“线程ID随机数”。解锁前先把value取出来比一下一致才删除。这样就算锁超时被别的线程接手了也不会误删别人的锁。不过说句实话setIfAbsent配合expire虽然能应付大多数场景但在极端情况下看门狗续期那些能力是没有的。如果业务确实需要长时间持有锁还是建议上Redisson。工具类能做的是让单机场景最简单可控。3.3 过期时间与缓存穿透处理缓存穿透这个事面试八股文里经常考但是代码里真正处理得出色的很少。常规做法是查DB查不到就在Redis里写一个null占位并设置较短过期时间比如30秒。但这里就遇到了上一节说的问题——如果你把null当成字符串null写进去等到下一次get的时候拿到null你怎么知道这是缓存里的空值还是真实数据就是字符串null我在工具类里做了一个包装层的标记。具体来说用JSON序列化时把null值场景单独封装成一个内部标记类private static final String EMPTY_VALUE ___EMPTY___;存空值的时候直接存这个常量字符串get的时候判断如果等于这个常量就返回null同时标记一个isEmpty的布尔值让上层业务知道这个数据是空占位而不是真实的缓存数据。另外就是过期时间的随机化。如果几千个key同时设置的过期时间都一样到了失效那一刻Redis会同时触发一大批过期删除CPU瞬间飙升主线程阻塞出现集中卡顿。所以工具类里我提供了一项“基础过期时间 随机抖动”的策略public static Duration randomExpire(Duration base) { long baseSeconds base.getSeconds(); long jitterSeconds ThreadLocalRandom.current().nextLong(0, 300); return Duration.ofSeconds(baseSeconds jitterSeconds); }3.4 批量操作与Hash结构封装业务中经常会遇到批量获取多个key的需求。比如有一次我做商品列表页需要一次性展示100个商品的名称和价格如果for循环100次get网络往返100次性能完全没法看。工具类里批量get用了opsForValue().multiGet一次性管道跟Redis通信比如获取多个用户信息就可以public static T ListT multiGet(ListString keys, ClassT clazz) { ListString jsonValues redisTemplate.opsForValue().multiGet(keys); return jsonValues.stream() .map(json - deserialize(json, clazz)) .collect(Collectors.toList()); }注意multiGet返回的List顺序和传入的keys是对应的所以下标的处理要留意null值。Hash结构我也封装了一套常用方法毕竟很多业务场景比如购物车、点赞状态天然适合hash存储public static void hashPut(String key, String hashKey, Object value) { String jsonValue serialize(value); redisTemplate.opsForHash().put(key, hashKey, jsonValue); } public static T T hashGet(String key, String hashKey, ClassT clazz) { Object value redisTemplate.opsForHash().get(key, hashKey); if (value null) { return null; } return deserialize(value.toString(), clazz); }hash的field建议直接用字符串不要序列化成对象否则取出来看不清楚排错会很痛苦。4. 关键坑点与排查思路实录4.1 缓存和数据库的一致性怎么保证很多面试背八股文的人都喜欢说“先删缓存再更新数据库”或者“先更新数据库再删缓存”问到底其实说不清为什么。我在项目里的做法比较简单粗暴更新数据库成功之后删除对应缓存让缓存自然重建。这种策略叫Cache Aside Pattern。但这里有个前提删除缓存这个动作可能失败。比如Redis短暂抖动或者网络超时。所以我在工具类里内置了一个简单的重试机制删除失败最多重试3次中间退避100毫秒public static void deleteWithRetry(String key, int retryTimes) { for (int i 0; i retryTimes; i) { try { redisTemplate.delete(key); return; } catch (Exception e) { if (i retryTimes - 1) { log.error(删除Redis缓存失败key{}, key, e); } else { Thread.sleep(100L * (i 1)); } } } }这个重试不解决所有问题比如Redis彻底挂掉的时候你再怎么重试也没用。但可以配合本地事务消息表来兜底这里不展开只是提醒大家“删除缓存”这个动作本身就值得被认真对待。4.2 LocalDateTime序列化出错这是Java项目里的高频问题。实体类里有LocalDateTime字段用Jackson序列化的时候如果不做特殊配置默认会报InvalidDefinitionException: Java 8 date/time type not supported。处理办法有两个方向一是在实体类的日期字段上加JsonFormat注解二是给ObjectMapper注册JavaTimeModule。我用的是后者因为在工具类里做一个全局的处理比每个字段加注解省心多了ObjectMapper objectMapper new ObjectMapper(); objectMapper.registerModule(new JavaTimeModule()); objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);这里要特别注意WRITE_DATES_AS_TIMESTAMPS必须disable掉否则LocalDateTime会被序列化成一个数组形如[2026,1,1,12,30,0]可读性极差别的服务解析也会莫名其妙。4.3 大Key和热Key问题工具类再完备也拦不住业务把大对象直接塞Redis。我之前接手过一个项目有个接口会把用户近一年的操作记录全查出来塞进一个key里value有几十MB。结果Redis每次返回这个key都要走慢查询日志整个Redis实例都被拖慢了。工具类层面能做的是提供序列化前的大小检查接口在写入前判断value的字节数超过设定阈值比如1MB就打日志告警public static void setWithSizeCheck(String key, Object value, Duration timeout) { String jsonValue serialize(value); long byteSize jsonValue.getBytes(StandardCharsets.UTF_8).length; if (byteSize LARGE_KEY_THRESHOLD) { log.warn(缓存value过大key{}, size{} bytes, key, byteSize); } redisTemplate.opsForValue().set(key, jsonValue, timeout); }至于热Key工具类可以做的是在get方法上加上统计计数比如用redisTemplate自身的慢查询日志判断但更有效的手段还是依靠Redis集群的分片策略和本地缓存兜底。工具类在这块的定位是“提醒”而非“根治”。4.4 常见问题速查表问题现象可能原因排查建议key在命令行看不到或乱码序列化器不是Stringkey带了二进制前缀检查RedisTemplate的keySerializer反序列化报ClassCastException序列化时没写入类型信息改用GenericJackson2JsonRedisSerializer或指定ObjectMapper的activateDefaultTypingLocalDateTime转换报错ObjectMapper没注册JavaTimeModule按4.2设置ObjectMapper分布式锁偶尔失效解锁时没有校验持有者标识检查unlock逻辑是否做了requestId比对缓存穿透严重null值缓存策略没生效检查空值占位是否被当成了正常缓存处理大批key同时过期导致卡顿过期时间没有加随机抖动使用randomExpire逻辑5. 工具类的扩展思路与更多的场景封装5.1 限流器的简单封装Redis做限流的方式很多固定窗口、滑动窗口、令牌桶。工具类里我沉淀了一个最简单的固定窗口限流器思路是利用INCREXPIREpublic static boolean rateLimit(String key, long limitCount, long windowSeconds) { String realKey buildKey(ratelimit, key); Long count redisTemplate.opsForValue().increment(realKey); if (count ! null count 1L) { redisTemplate.expire(realKey, Duration.ofSeconds(windowSeconds)); } return count ! null count limitCount; }这个方法60行代码不到但能挡住很多突发流量。注意increment后要设置过期时间且要用判断返回是否为1来设置过期这样保证窗口期是对的。5.2 幂等性支持接口幂等是后端里绕不开的话题。我习惯用Redis实现一个轻量级的幂等控制请求进来时根据业务ID生成幂等key用setIfAbsent尝试写入能写进去说明是第一次请求写不进去说明是重复请求。public static boolean tryIdempotent(String businessType, String businessId, Duration timeout) { String key buildKey(idempotent, businessType : businessId); return Boolean.TRUE.equals(redisTemplate.opsForValue().setIfAbsent(key, 1, timeout)); }这个方案在大多数场景下够用但要注意如果业务处理时间超过了timeout那第二次相同请求进来的时候key已经过期幂等就失效了。这种场景就需要把过期时间设置得比最长业务处理时间长一些或者用一套更严格的状态机方案。5.3 消息队列的简化版封装Redis的List结构可以用来做简单的任务队列但用的时候务必小心LPUSH BRPOP这种组合是经典的可靠队列模式。我在工具类里提供了一左一右两个方法方便生产消费模型的快速搭建public static void leftPush(String queueName, Object message) { String jsonMessage serialize(message); redisTemplate.opsForList().leftPush(queueName, jsonMessage); } public static T T rightPop(String queueName, ClassT clazz) { String jsonMessage redisTemplate.opsForList().rightPop(queueName); if (jsonMessage null) { return null; } return deserialize(jsonMessage, clazz); }如果你有可靠性要求更高的场景比如消费后处理失败要重新入队那还是建议用Stream或者专门的MQList队列只能保证顺序不能保证不丢消息。5.4 布隆过滤器思想在缓存里的落地布隆过滤器能用来解决缓存穿透问题但不是让你在代码里手动去写一个Bit数组操作。Redis 4.0之后有了module机制如果你的服务器装了布隆过滤器插件用起来很舒服。如果没装一个折中的办法是在工具类里维护一个“存在的ID集合”用Set结构搞定不过这个集合会膨胀用完要定期清理。真正要长期做高并发缓存穿透防护的还是要上布隆过滤器。方法层面可以封装成这样public static boolean isBloomPermitted(String key) { // 底层调用Redis布隆过滤器插件的BF.EXISTS命令 return redisTemplate.execute((RedisCallbackBoolean) connection - connection.execute(BF.EXISTS, new byte[][]{serializeKey(key), serializeKey(key)})); }不展开讲了这块内容在面试里经常会被追问先把思路理清楚代码你就知道怎么写了。6. 实操心得这套工具类在我项目里的演进路线这套RedisUtils不是一天写成的。第一版就是简单set、get后来加了过期时间再后来开始有人问“为什么我的数据取出来是LinkedHashMap”于是加了泛型反序列化。再后来订单系统接进来分布式锁和幂等控制才逐步加上。如果要我总结一条演进路线大概是这么几步第一步先解决“能用”封装set、get、delete、expire这些最基础的方法。第二步解决“好用”定好key规范加好日志把LocalDateTime这类常见坑提前踩平。第三步解决“规模化使用”提供分布式锁、限流、幂等这些通用能力让业务方一行代码接入。第四步解决“可观测”写入前的大key检测、执行耗时的慢日志统计、序列化失败的异常归类。每一步都有对应的痛点在驱动不是为了封装而封装。我个人在实践中的一个感受是工具类代码写得好不好不是看用了多少设计模式、多少Google Guava的API而是看它能不能让业务方少写重复代码、少趟坑。如果业务方使用工具类半天搞不定一个需求还要翻你源码那一定是我封装的接口设计有问题。所以每次有新的方法要加进来我都会问自己三个问题这个方法90%的场景是不是只需要一个参数方法名能不能让新人一眼看懂如果参数记错了能不能在编译期就报错而不是运行期才炸比如set方法有时候需要传过期时间有时候不需要我就干脆别重载直接用Duration类型强制让调用方传值。如果过期时间没传或者传了null内部默认为30分钟。这样比搞一堆重载方法要清晰得多。另外还有一个心得工具类里所有对外方法都应当是“无状态的静态方法”或者通过Spring注入的Bean方法。不要在里面持有任何可变的全局状态否则在高并发下会出各种诡异的问题。我最早版本犯过这个错误在一个静态Map里存了一些临时数据结果线上时不时出现串数据的问题排查了一整天才发现是那个Map在作祟。至于如何判断工具类封装的边界我的建议是跟Redis操作强相关的逻辑放进来业务判断逻辑绝不放进来。比如“这个key是否属于VIP用户”这种判断就绝不该出现在Redis工具类里否则工具类迟早变成一个垃圾场。这套工具类目前在我们项目里支撑着包括用户会话、商品缓存、订单幂等、接口防刷在内的多个核心场景每天的调用量在上亿次级别稳定性经受住了考验。当然它不完美比如缺少对Redisson的深度整合、没有做操作耗时统计上报、没有接入统一的监控大盘。这些都是我下一步想优化的方向。如果你也在维护自己的Redis工具类希望这篇文章能给你一些参考。尤其是那些容易被人忽略的细节——序列化类型、key规范、加锁解锁的标识校验、过期时间的随机化——一个不留神就是线上事故的导火索。最后还是那句话封装工具类不是炫技能让你和你的团队用得省心、出了问题能快速定位就是最好的工具类。
RedisUtils工具类封装实战：从RedisTemplate到分布式锁与缓存穿透
1. 为什么我坚持自己封装一个RedisUtils而不是直接用Spring Data Redis先说个面试场景。很多候选人简历上都写着“熟悉Redis”结果我问到“你们项目里的Redis工具类是怎么封装的”十有八九会愣一下然后告诉我“我们直接用的RedisTemplate”。这个回答倒也不算错但你要是做过三五个中型以上项目就会发现直接拿RedisTemplate裸奔代码里会躺满一堆重复的、容易踩坑的样板代码。比如key拼接、序列化配置、分布式锁的实现、缓存的空值处理这些逻辑散落在service层各处改一个序列化方案可能要动几百处调用。我自己在项目里维护了一套RedisUtils工具类沉淀了好几年踩过不少坑也重构过好几轮。这篇文章把这套东西的核心设计思路和完整实现拆开讲清楚包括为什么有些地方要这么写、哪些做法看起来正确但实际会埋雷、以及在并发场景下怎么保证不翻车。如果你是刚接触Java后端、想理解Redis工具类到底该怎么封装的同学或者已经写了一阵子Redis但总觉得代码别扭的同行这篇文章应该能给你一些可落地的参考。先说清楚这套工具类的定位它不是要替代RedisTemplate而是在RedisTemplate之上做一层薄封装解决三个最痛的问题规范key的生成和管理避免散落各处的手写字符串拼接统一序列化策略防止LocalDateTime、空对象这类东西在存取时搞出幺蛾子把分布式锁、限流、幂等等高频场景封装成一行调用降低使用成本2. 工具类设计的核心思路与整体结构2.1 先想清楚这层封装到底放在哪一层很多项目里你会看到这样的调用方式service层直接用stringRedisTemplate.opsForValue().set(key, value)然后一堆魔法字符串散落在业务代码里。这其实不叫封装这叫绕过了封装。我的思路是不管底层你是谁service层永远只跟RedisUtils互动。这样底层无论从Jedis换成Lettuce还是从StringRedisTemplate换成自定义序列化的RedisTemplate对上层业务都是无感的。整个结构分三层接口层对外暴露的方法比如set、get、delete、expire、lock语义要清楚。核心实现层基于StringRedisTemplate完成具体操作处理序列化、解析、重试这些脏活累活。底层配置层负责创建RedisTemplate的bean、设置序列化器、配置连接工厂。2.2 序列化策略的选择决定了你会不会半夜被叫起来这是整个工具类里最容易出幺蛾子的地方。默认的JdkSerializationRedisSerializer会把对象序列化成一堆二进制字节存在Redis里的key会带一串乱码前缀\xAC\xED\x00\x05t\x00你在命令行里根本没法直观排查数据。而且一旦实体类结构变更了反序列化版本号老的缓存数据就全废了。我最终采用的是StringRedisTemplate 手动JSON序列化的方式。也就是说往Redis里放对象的时候提前把它转成JSON字符串取出来的时候反序列化成目标类型。这种方式牺牲了一点点自动化的便利性但换来的是缓存数据直读、跨语言可解析、升级兼容性好。实际项目中我用的是Jackson来做序列化尽量不用Fastjson一方面是维护活跃度的问题另一方面Jackson对复杂泛型和Java时间类型的支持更规范一些。序列化的核心配置我放在一个单独的RedisConfig类里大致是这么写的Configuration public class RedisConfig { Bean public RedisTemplateString, String redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, String template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashKeySerializer(stringSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }注意这里value序列化器用的是GenericJackson2JsonRedisSerializer而不是Jackson2JsonRedisSerializer。后者的默认构造不会带上类型信息反序列化的时候拿到手的是LinkedHashMap你强转成自定义对象就报ClassCastException。这个坑我至少见过三个同事踩过。2.3 命名规范key跟前缀后缀的设计逻辑key的设计直接关系到线上问题排查的效率。我推荐这样的规范业务模块:业务实体:唯一标识:字段比如用户信息的key就是user:info:1001订单列表的分页缓存就是order:page:1001:1:20。在工具类里我会内置一个方法把模块名和业务标识拼接起来统一加上系统级前缀避免多个服务共用同一个Redis实例时key冲突private static final String GLOBAL_PREFIX myapp:; private String buildKey(String module, String key) { return GLOBAL_PREFIX module : key; }这样做的好处是在Redis Desktop Manager或者命令行里按myapp:user:*就能一眼看到某个模块的全部缓存。不要小看这个设计等缓存数据量上来了定位问题时这个前缀就是救命稻草。3. 核心功能实现与实操细节3.1 缓存的存取set与get完整实现工具类最基础的操作就是存字符串和对象。字符串直接存对象转JSON存。这里的重点在于过期时间的单位统一。很多人用着用着就搞混秒和毫秒我干脆统一对外暴露的接口都用Duration或者秒内部再转换public static void set(String key, Object value, Duration timeout) { String jsonValue serialize(value); redisTemplate.opsForValue().set(key, jsonValue, timeout); } public static T T get(String key, ClassT clazz) { String jsonValue redisTemplate.opsForValue().get(key); if (jsonValue null) { return null; } return deserialize(jsonValue, clazz); }序列化和反序列化我单独的私有方法处理序列化时做个判空避免包装成JSON字符串的时候把null也变成一个字符串null存进去导致缓存穿透判断失效。还有一个细节get的时候要区分“key不存在”和“key存在但是值为空”。这在后面处理缓存穿透时非常关键。3.2 分布式锁的正确姿势分布式锁是工具类里的重头戏。如果你只是用setnx加锁、用del解锁那大概率会在高并发下出问题线程A的锁还没释放就超时了线程B拿到锁开始执行线程A执行完后把B的锁给删了直接锁失效。有人会说用Redisson确实Redisson的看门狗机制解决了很多问题。但如果你不想引入额外的依赖直接用Redis原生命令也能写出还算靠谱的锁。核心就是两点一是加锁时要带上唯一标识二是解锁时要校验该标识。我在工具类里封装了lock和unlockpublic static boolean lock(String lockKey, String requestId, long expireSeconds) { String key buildKey(lock, lockKey); return redisTemplate.opsForValue().setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public static void unlock(String lockKey, String requestId) { String key buildKey(lock, lockKey); String value redisTemplate.opsForValue().get(key); if (requestId.equals(value)) { redisTemplate.delete(key); } }看到没有requestId就是那个唯一标识可以用UUID生成也可以用“线程ID随机数”。解锁前先把value取出来比一下一致才删除。这样就算锁超时被别的线程接手了也不会误删别人的锁。不过说句实话setIfAbsent配合expire虽然能应付大多数场景但在极端情况下看门狗续期那些能力是没有的。如果业务确实需要长时间持有锁还是建议上Redisson。工具类能做的是让单机场景最简单可控。3.3 过期时间与缓存穿透处理缓存穿透这个事面试八股文里经常考但是代码里真正处理得出色的很少。常规做法是查DB查不到就在Redis里写一个null占位并设置较短过期时间比如30秒。但这里就遇到了上一节说的问题——如果你把null当成字符串null写进去等到下一次get的时候拿到null你怎么知道这是缓存里的空值还是真实数据就是字符串null我在工具类里做了一个包装层的标记。具体来说用JSON序列化时把null值场景单独封装成一个内部标记类private static final String EMPTY_VALUE ___EMPTY___;存空值的时候直接存这个常量字符串get的时候判断如果等于这个常量就返回null同时标记一个isEmpty的布尔值让上层业务知道这个数据是空占位而不是真实的缓存数据。另外就是过期时间的随机化。如果几千个key同时设置的过期时间都一样到了失效那一刻Redis会同时触发一大批过期删除CPU瞬间飙升主线程阻塞出现集中卡顿。所以工具类里我提供了一项“基础过期时间 随机抖动”的策略public static Duration randomExpire(Duration base) { long baseSeconds base.getSeconds(); long jitterSeconds ThreadLocalRandom.current().nextLong(0, 300); return Duration.ofSeconds(baseSeconds jitterSeconds); }3.4 批量操作与Hash结构封装业务中经常会遇到批量获取多个key的需求。比如有一次我做商品列表页需要一次性展示100个商品的名称和价格如果for循环100次get网络往返100次性能完全没法看。工具类里批量get用了opsForValue().multiGet一次性管道跟Redis通信比如获取多个用户信息就可以public static T ListT multiGet(ListString keys, ClassT clazz) { ListString jsonValues redisTemplate.opsForValue().multiGet(keys); return jsonValues.stream() .map(json - deserialize(json, clazz)) .collect(Collectors.toList()); }注意multiGet返回的List顺序和传入的keys是对应的所以下标的处理要留意null值。Hash结构我也封装了一套常用方法毕竟很多业务场景比如购物车、点赞状态天然适合hash存储public static void hashPut(String key, String hashKey, Object value) { String jsonValue serialize(value); redisTemplate.opsForHash().put(key, hashKey, jsonValue); } public static T T hashGet(String key, String hashKey, ClassT clazz) { Object value redisTemplate.opsForHash().get(key, hashKey); if (value null) { return null; } return deserialize(value.toString(), clazz); }hash的field建议直接用字符串不要序列化成对象否则取出来看不清楚排错会很痛苦。4. 关键坑点与排查思路实录4.1 缓存和数据库的一致性怎么保证很多面试背八股文的人都喜欢说“先删缓存再更新数据库”或者“先更新数据库再删缓存”问到底其实说不清为什么。我在项目里的做法比较简单粗暴更新数据库成功之后删除对应缓存让缓存自然重建。这种策略叫Cache Aside Pattern。但这里有个前提删除缓存这个动作可能失败。比如Redis短暂抖动或者网络超时。所以我在工具类里内置了一个简单的重试机制删除失败最多重试3次中间退避100毫秒public static void deleteWithRetry(String key, int retryTimes) { for (int i 0; i retryTimes; i) { try { redisTemplate.delete(key); return; } catch (Exception e) { if (i retryTimes - 1) { log.error(删除Redis缓存失败key{}, key, e); } else { Thread.sleep(100L * (i 1)); } } } }这个重试不解决所有问题比如Redis彻底挂掉的时候你再怎么重试也没用。但可以配合本地事务消息表来兜底这里不展开只是提醒大家“删除缓存”这个动作本身就值得被认真对待。4.2 LocalDateTime序列化出错这是Java项目里的高频问题。实体类里有LocalDateTime字段用Jackson序列化的时候如果不做特殊配置默认会报InvalidDefinitionException: Java 8 date/time type not supported。处理办法有两个方向一是在实体类的日期字段上加JsonFormat注解二是给ObjectMapper注册JavaTimeModule。我用的是后者因为在工具类里做一个全局的处理比每个字段加注解省心多了ObjectMapper objectMapper new ObjectMapper(); objectMapper.registerModule(new JavaTimeModule()); objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);这里要特别注意WRITE_DATES_AS_TIMESTAMPS必须disable掉否则LocalDateTime会被序列化成一个数组形如[2026,1,1,12,30,0]可读性极差别的服务解析也会莫名其妙。4.3 大Key和热Key问题工具类再完备也拦不住业务把大对象直接塞Redis。我之前接手过一个项目有个接口会把用户近一年的操作记录全查出来塞进一个key里value有几十MB。结果Redis每次返回这个key都要走慢查询日志整个Redis实例都被拖慢了。工具类层面能做的是提供序列化前的大小检查接口在写入前判断value的字节数超过设定阈值比如1MB就打日志告警public static void setWithSizeCheck(String key, Object value, Duration timeout) { String jsonValue serialize(value); long byteSize jsonValue.getBytes(StandardCharsets.UTF_8).length; if (byteSize LARGE_KEY_THRESHOLD) { log.warn(缓存value过大key{}, size{} bytes, key, byteSize); } redisTemplate.opsForValue().set(key, jsonValue, timeout); }至于热Key工具类可以做的是在get方法上加上统计计数比如用redisTemplate自身的慢查询日志判断但更有效的手段还是依靠Redis集群的分片策略和本地缓存兜底。工具类在这块的定位是“提醒”而非“根治”。4.4 常见问题速查表问题现象可能原因排查建议key在命令行看不到或乱码序列化器不是Stringkey带了二进制前缀检查RedisTemplate的keySerializer反序列化报ClassCastException序列化时没写入类型信息改用GenericJackson2JsonRedisSerializer或指定ObjectMapper的activateDefaultTypingLocalDateTime转换报错ObjectMapper没注册JavaTimeModule按4.2设置ObjectMapper分布式锁偶尔失效解锁时没有校验持有者标识检查unlock逻辑是否做了requestId比对缓存穿透严重null值缓存策略没生效检查空值占位是否被当成了正常缓存处理大批key同时过期导致卡顿过期时间没有加随机抖动使用randomExpire逻辑5. 工具类的扩展思路与更多的场景封装5.1 限流器的简单封装Redis做限流的方式很多固定窗口、滑动窗口、令牌桶。工具类里我沉淀了一个最简单的固定窗口限流器思路是利用INCREXPIREpublic static boolean rateLimit(String key, long limitCount, long windowSeconds) { String realKey buildKey(ratelimit, key); Long count redisTemplate.opsForValue().increment(realKey); if (count ! null count 1L) { redisTemplate.expire(realKey, Duration.ofSeconds(windowSeconds)); } return count ! null count limitCount; }这个方法60行代码不到但能挡住很多突发流量。注意increment后要设置过期时间且要用判断返回是否为1来设置过期这样保证窗口期是对的。5.2 幂等性支持接口幂等是后端里绕不开的话题。我习惯用Redis实现一个轻量级的幂等控制请求进来时根据业务ID生成幂等key用setIfAbsent尝试写入能写进去说明是第一次请求写不进去说明是重复请求。public static boolean tryIdempotent(String businessType, String businessId, Duration timeout) { String key buildKey(idempotent, businessType : businessId); return Boolean.TRUE.equals(redisTemplate.opsForValue().setIfAbsent(key, 1, timeout)); }这个方案在大多数场景下够用但要注意如果业务处理时间超过了timeout那第二次相同请求进来的时候key已经过期幂等就失效了。这种场景就需要把过期时间设置得比最长业务处理时间长一些或者用一套更严格的状态机方案。5.3 消息队列的简化版封装Redis的List结构可以用来做简单的任务队列但用的时候务必小心LPUSH BRPOP这种组合是经典的可靠队列模式。我在工具类里提供了一左一右两个方法方便生产消费模型的快速搭建public static void leftPush(String queueName, Object message) { String jsonMessage serialize(message); redisTemplate.opsForList().leftPush(queueName, jsonMessage); } public static T T rightPop(String queueName, ClassT clazz) { String jsonMessage redisTemplate.opsForList().rightPop(queueName); if (jsonMessage null) { return null; } return deserialize(jsonMessage, clazz); }如果你有可靠性要求更高的场景比如消费后处理失败要重新入队那还是建议用Stream或者专门的MQList队列只能保证顺序不能保证不丢消息。5.4 布隆过滤器思想在缓存里的落地布隆过滤器能用来解决缓存穿透问题但不是让你在代码里手动去写一个Bit数组操作。Redis 4.0之后有了module机制如果你的服务器装了布隆过滤器插件用起来很舒服。如果没装一个折中的办法是在工具类里维护一个“存在的ID集合”用Set结构搞定不过这个集合会膨胀用完要定期清理。真正要长期做高并发缓存穿透防护的还是要上布隆过滤器。方法层面可以封装成这样public static boolean isBloomPermitted(String key) { // 底层调用Redis布隆过滤器插件的BF.EXISTS命令 return redisTemplate.execute((RedisCallbackBoolean) connection - connection.execute(BF.EXISTS, new byte[][]{serializeKey(key), serializeKey(key)})); }不展开讲了这块内容在面试里经常会被追问先把思路理清楚代码你就知道怎么写了。6. 实操心得这套工具类在我项目里的演进路线这套RedisUtils不是一天写成的。第一版就是简单set、get后来加了过期时间再后来开始有人问“为什么我的数据取出来是LinkedHashMap”于是加了泛型反序列化。再后来订单系统接进来分布式锁和幂等控制才逐步加上。如果要我总结一条演进路线大概是这么几步第一步先解决“能用”封装set、get、delete、expire这些最基础的方法。第二步解决“好用”定好key规范加好日志把LocalDateTime这类常见坑提前踩平。第三步解决“规模化使用”提供分布式锁、限流、幂等这些通用能力让业务方一行代码接入。第四步解决“可观测”写入前的大key检测、执行耗时的慢日志统计、序列化失败的异常归类。每一步都有对应的痛点在驱动不是为了封装而封装。我个人在实践中的一个感受是工具类代码写得好不好不是看用了多少设计模式、多少Google Guava的API而是看它能不能让业务方少写重复代码、少趟坑。如果业务方使用工具类半天搞不定一个需求还要翻你源码那一定是我封装的接口设计有问题。所以每次有新的方法要加进来我都会问自己三个问题这个方法90%的场景是不是只需要一个参数方法名能不能让新人一眼看懂如果参数记错了能不能在编译期就报错而不是运行期才炸比如set方法有时候需要传过期时间有时候不需要我就干脆别重载直接用Duration类型强制让调用方传值。如果过期时间没传或者传了null内部默认为30分钟。这样比搞一堆重载方法要清晰得多。另外还有一个心得工具类里所有对外方法都应当是“无状态的静态方法”或者通过Spring注入的Bean方法。不要在里面持有任何可变的全局状态否则在高并发下会出各种诡异的问题。我最早版本犯过这个错误在一个静态Map里存了一些临时数据结果线上时不时出现串数据的问题排查了一整天才发现是那个Map在作祟。至于如何判断工具类封装的边界我的建议是跟Redis操作强相关的逻辑放进来业务判断逻辑绝不放进来。比如“这个key是否属于VIP用户”这种判断就绝不该出现在Redis工具类里否则工具类迟早变成一个垃圾场。这套工具类目前在我们项目里支撑着包括用户会话、商品缓存、订单幂等、接口防刷在内的多个核心场景每天的调用量在上亿次级别稳定性经受住了考验。当然它不完美比如缺少对Redisson的深度整合、没有做操作耗时统计上报、没有接入统一的监控大盘。这些都是我下一步想优化的方向。如果你也在维护自己的Redis工具类希望这篇文章能给你一些参考。尤其是那些容易被人忽略的细节——序列化类型、key规范、加锁解锁的标识校验、过期时间的随机化——一个不留神就是线上事故的导火索。最后还是那句话封装工具类不是炫技能让你和你的团队用得省心、出了问题能快速定位就是最好的工具类。
