当前位置：首页 > 问答 > 正文

Redis通用封装那点事儿，怎么搞得更简单又实用

芮以莲
问答
2026-01-09 10:49:03
5

说到Redis的封装，很多开发者的第一感觉就是：有必要吗？直接用set、get不香吗？刚开始项目小，确实觉得直接挺方便，但随着项目变大，团队人变多，问题就一个个冒出来了，不同的程序员对同一个数据结构的命名规则不一样，有的用冒号分隔user:123，有的用下划线user_123，搞得Redis里乱七八糟，再比如，有人不小心用相同的key覆盖了别人的数据，或者该设置过期时间的没设置,导致内存泄漏。

封装的核心目的就两个：一是统一规范，二是简化操作，说白了，就是立规矩，让后面的人能少踩坑,写代码能更省事儿。

那怎么才能把这事儿搞得既简单又实用呢？别搞得太复杂，整得像要重写一个Redis客户端似的，那就本末倒置了，根据一些常见的实践，比如知乎上“可爱的Tom”工程师提到的思路,可以抓住下面几个关键点来搞。

第一点，先搞定Key的管理，这是混乱的源头。 你不能让每个程序员自己拍脑袋决定key怎么拼，一个比较实用的办法是，用一个专门的方法来生成key，你可以定义一个KeyBuilder（键构建器）类,里面全是静态方法。

举个例子：

Redis通用封装那点事儿，怎么搞得更简单又实用

public class RedisKey {
    public static String getUserKey(Long userId) {
        return String.format("user:info:%s", userId);
    }
    public static String getOrderKey(String orderNo) {
        return String.format("order:detail:%s", orderNo);
    }
    public static String getSmsCodeKey(String phone) {
        return String.format("sms:code:%s", phone);
    }
}

这样一来，整个项目里，只要是取用户信息的key，都必须调用RedisKey.getUserKey(123)，得到的结果永远是user:info:123，这就强制统一了命名规范，清晰又不会重复，这种方法非常直接,也容易理解。

第二点，把常用的操作封装成更语义化的方法。 直接使用jedis.set(key, value)或者lettuce的命令，意图不够明显，我们可以包装一层,让方法名直接表达业务含义。

缓存用户信息：

Redis通用封装那点事儿，怎么搞得更简单又实用

@Component
public class UserCacheService {
    @Autowired
    private RedisTemplate redisTemplate;
    public void setUser(User user, long timeout, TimeUnit unit) {
        String key = RedisKey.getUserKey(user.getId());
        // 这里可以统一处理序列化等问题
        redisTemplate.opsForValue().set(key, user, timeout, unit);
    }
    public User getUser(Long userId) {
        String key = RedisKey.getUserKey(userId);
        return (User) redisTemplate.opsForValue().get(key);
    }
    // 特别常用的，比如设置带默认过期时间的
    public void setUserWithDefaultExpire(User user) {
        setUser(user, 30, TimeUnit.MINUTES); // 默认缓存30分钟
    }
}

你看，这样封装后，业务代码里写的是userCacheService.setUserWithDefaultExpire(user)，一看就知道是在缓存用户信息，并且有默认过期时间，这比原生的setex命令要直观多了，这种封装是针对特定业务的,非常实用。

第三点，处理一些常见的“坑”。

序列化问题：Java对象存Redis需要序列化，很多人直接用JDK序列化，结果存进去的数据是二进制的，看不明白，还不兼容其他语言，一个简单的改进是统一用JSON序列化（比如Jackson），这样数据可读性好，也方便其他系统调试，在封装的时候，可以在工具类内部统一做好对象的序列化和反序列化,对外只暴露Java对象。
连接管理：这事儿一般不用我们自己操心，Spring Boot的RedisTemplate或者Lettuce/Jedis连接池已经处理得很好了，封装时确保使用的是这些成熟方案,而不是自己造轮子。
分布式锁：这是一个非常常见的需求，如果项目里到处是setnx命令，又容易出错，完全可以封装一个简单的分布式锁工具类，比如提供tryLock、unlock方法，内部处理好锁的获取、过期时间设置、原子性等问题（可以参考Redis官方推荐的Redlock算法思想，但简单场景用setnx加过期时间也行）,让业务方一行代码就能用上安全的锁。

第四点，也是让封装更“简单”的秘诀：按需封装，不要过度设计。 你别一上来就想着设计一个能应对公司所有业务的超级通用Redis框架，大概率会设计得特别复杂，最后还没人用,最实用的做法是：

从当前项目最痛的点入手：如果现在是key的命名混乱,那就先搞定Key的管理。
发现重复代码再提取：当发现多个地方都在写类似的缓存逻辑时,再把这些逻辑收拢成一个通用的方法。
渐进式增强：先解决80%的常见场景，剩下20%的特殊场景，如果一时半会儿封装起来很别扭，可以先放一放，暂时用原生方法甚至SQL查询代替,以后有需要再重构。

Redis封装没那么神秘，它就是给散兵游勇式的Redis使用方式立规矩、建流程，核心就是：管好Key、简化常用操作、解决常见痛点，并且一步一步来，这样搞出来的封装，代码量不大，但能极大地提升开发效率和代码质量，维护起来也轻松,这才是简单又实用的做法。