面对缓存，有哪些问题需要思考？

作者: 家榆_77cd | 来源:发表于2017-10-19 15:10 被阅读0次

缓存可以说是无处不在，比如：PC电脑中的内存、CPU中有二级缓存、http协议中的缓存控制、CDN加速技术无不都是使用了缓存的思想来解决性能问题。

缓存是用于解决高并发场景下系统的性能及稳定性问题的银弹。

本文主要是讨论我们经常使用的分布式缓存Redis在开发过程中需要考虑的问题。

1. 如何将业务逻辑与缓存之间进行解耦？

大部分情况，大家都是把缓存操作和业务逻辑之间的代码交织在一起的，比如（代码一）：

public UserServiceImpl implements UserService {
    @Autowired
    private RedisTemplate<String, User> redisTemplate;
    
    @Autowired
    private UserMapper userMapper;
    
    public User getUserById(Long userId) {
        String cacheKey = "user_" + userId;
        User user = redisTemplate.opsForValue().get(cacheKey);
        if(null != user) {
            return user;
        }
        user = userMapper.getUserById(userId);
        redisTemplate.opsForValue().set(cacheKey, user); // 如果user 为null时，缓存就没有意义了
        return user;
    }
    
    public void deleteUserById(Long userId) {
        userMapper.deleteUserById(userId);
        String cacheKey = "user_" + userId;
        redisTemplate.opsForValue().del(cacheKey);
    }
}

从上面的代码可以看出以下几个问题：

缓存操作非常繁琐，产生非常多的重复代码；
缓存操作与业务逻辑耦合度非常高，不利于后期的维护；
当业务数据为null时，无法确定是否已经缓存，会造成缓存无法命中；
开发阶段，为了排查问题，经常需要来回开关缓存功能，使用上面的代码是无法做到很方便地开关缓存功能；
当业务越来越复杂时，使用缓存的地方越来越多时，很难定位哪些数据要进行主动删除；
如果不想用Redis，换用别的缓存技术的话，那是多么痛苦的一件事。

因为高耦合带来的问题还很多，就不一一列举了。接下来介绍笔者开源的一个缓存管理框架：AutoLoadCache是如何帮助我们来解决上述问题的。

借鉴于Spring cache的思想使用AOP + Annotation 等技术实现缓存与业务逻辑的解耦。我们再用AutoLoadCache 来重构上面的代码，进行对比（代码二）：

public interface UserMapper {
    @Cache(expire = 120, key = "'user_' + #args[0]")
    User getUserById(Long userId);
    
    @CacheDelete({ @CacheDeleteKey(value = "'user' + #args[0].id") })
    void updateUser(User user);
}

public UserServiceImpl implements UserService {
    
    @Autowired
    private UserMapper userMapper;
    
    public User getUserById(Long userId) {
        return userMapper.getUserById(userId);
    }
    @Transactional(rollbackFor=Throwable.class)
    public void updateUser(User user) {
        userMapper.updateUser(user);
    }
}

AutoloadCache 在AOP拦截到请求后，大概的流程如下：

获取到拦截方法的@Cache注解，并生成缓存key；
通过缓存key，去缓存中获取数据；
如果缓存命中，执行如下流程：
1. 如果需要自动加载，则把相关信息保存到自动加载队列中；
2. 否则判断缓存是否即将过期，如果即将过期，则会发起异步刷新；
3. 最后把数据返回给用户；
如果缓存没有命中，执行如下流程：
1. 选举出一个leader回到数据源中去加载数据，加载到数据后通知其它请求从内存中获取数据（拿来主义机制）；
2. leader负责把数据写入缓存；如果需要自动加载，则把相关信息保存到自动加载队列中；
3. 最后把数据返回给用户；

这里提到的异步刷新、自动加载、拿来主义机制，我们会在后面再说明。

2. 对缓存进行“包装”

上面代码一的例子中，当从数据源获取的数据为null时，缓存就没有意义了，所获取这个数据的请求，都会回到数据源去获取数据。当请求量非常大的话，会造成数据源负载过高而宕机。所以对于null的数据，需要做特殊处理，比如使用特殊字符串进行替换。而在AutoloadCache中使用了一个包装器对所有缓存数据进行包装（代码三）：

public class CacheWrapper<T> implements Serializable, Cloneable {

    private T cacheObject; // 缓存数据

    private long lastLoadTime; // 加载时间

    private int expire; // 缓存时长
    
    /**
     * 判断缓存是否已经过期
     * @return boolean
     */
    public boolean isExpired() {
        if(expire > 0) {
            return (System.currentTimeMillis() - lastLoadTime) > expire * 1000;
        }
        return false;
    }
}

在这上面的代码中，除了封装了缓存数据外，还封装了数据加载时间和缓存时长，通过这两项数据，很容易判断缓存是否即将过期或者已经过期。

3. 如何提升缓存key生成表达式性能？

使用Annotation解决缓存与业务之间的耦合后，我们最主要的工作就是如何来设计缓存KEY了，缓存KEY设计的粒度越小，缓存的复用性也就越好。

上面例子中我们是使用Spring EL表达式来生成缓存KEY，有些人估计会担心Spring EL表达式的性能不好，或者不想用Spring的情况该怎么办？

框架中为了满足这些需求，支持扩展表达式解析器：继承com.jarvis.cache.script. AbstractScriptParser后就可以任你扩展。

框架现在除了支持Spring EL表达式外，还支持Ognl，javascript表达式。对于性能要求非常高的人，可以使用Ognl，它的性能非常接近原生代码。

4. 如何解决缓存Key冲突问题？

在实际情况中，可能有多个模块共用一个Redis服务器或是一个Redis集群的情况，那么有可能造成缓存key冲突了。

为了解决这个问题AutoLoadCache，增加了namespace。如果设置了namespace就会在每个缓存Key最前面增加namespace（代码四）：

public final class CacheKeyTO implements Serializable {

    private final String namespace;

    private final String key;// 缓存Key

    private final String hfield;// 设置哈希表中的字段，如果设置此项，则用哈希表进行存储

    public String getCacheKey() { // 生成缓存Key方法
        if(null != this.namespace && this.namespace.length() > 0) {
            return new StringBuilder(this.namespace).append(":").append(this.key).toString();
        }
        return this.key;
    }
}

5. 压缩缓存数据及提升序列化与反序列化性能

我们希望缓存数据包越小越好，能减少内存占用，以及减轻带宽压力；同时也要考虑序列化与反序列化的性能。

AutoLoadCache为了满足不同用户的需要，已经实现了基于JDK、Hessian、JacksonJson、Fastjson、JacksonMsgpack等技术序列化及反序列工具。也可以通过实现com.jarvis.cache.serializer.ISerializer 接口自行扩展。

JDK自带的序列化与反序列化工具产生的数据包非常大，而且性能也非常差，不建议大家使用；JacksonJson 和 Fastjson 是基于JSON的，所有用到缓存的函数的参数及返回值都必须是具体类型的，不能是不确定类型的（不能是Object, List<?>等），另外有些数据转成Json是其一些属性是会被忽略,存在这种情况时，也不能使用Json；
而Hessian 则是非常不错的选择，非常成熟和稳定性。阿里的dubbo和HSF两个RPC框架都是使用了Hessian进行序列化和返序列化。

6. 如何减少回源并发数？

当缓存未命中时，都需要回到数据源去取数据，如果这时有多个并发来请求相同一个数据（即相同缓存key请求），都回到数据源加载数据，并写缓存，造成资源极大的浪费，也可能造成数据源负载过高而无法服务。

AutoLoadCache 使用拿来主义机制和自动加载机制来解决这个问题：

拿来主义机制

拿来主交机制，指的是当有多个用户请求同一个数据时，会选举出一个leader去数据源加载数据，其它用户则等待其拿到的数据。并由leader将数据写入缓存。
自动加载机制

自动加载机制，将用户请求及缓存时间等信息放到一个队列中，后台使用线程池定期扫这个队列，发现缓存即将过期，则去数据源加载最新的数据放到缓存中。达到将数据长驻内存的效果。从而将这些数据的请求，全部引向了缓存，而不会回到数据源去获取数据。非常适合用于缓存使用非常频繁的数据，以及非常耗时的数据。

为了防止自动加载队列过大，设置了容量限制；同时会将超过一定时间没有用户请求的也会从自动加载队列中移除，把服务器资源释放出来，给真正需要的请求。

往缓存里写数据的性能相比读的性能差非常多，通过上面两种机制，可以减少写缓存的并发，提升缓存服务能力。

7. 异步刷新

AutoLoadCache 从缓存中获取到数据后，借助于上面提到的CacheWrapper，能很方便判断缓存是否即将过期，如果即将过期，则会把发起异步刷新请求。

使用异步刷新的目的，提前将数据缓存起来，避免缓存失效后，大量请求穿透到数据源。

8. 支持多种缓存操作

大部分情况下，我们都是对缓存进行读与写操作，可有时，我们只需要从缓存中读取数据，或者只写数据，那么可以通过 @Cache 的 opType 指定缓存操作类型。现支持以下几种操作类型：

READ_WRITE：读写缓存操:如果缓存中有数据，则使用缓存中的数据，如果缓存中没有数据，则加载数据，并写入缓存。默认是READ_WRITE；
WRITE：从数据源中加载最新的数据，并写入缓存。对数据源和缓存数据进行同步；
READ_ONLY：只从缓存中读取，并不会去数据源加载数据。用于异地读写缓存的场景；
LOAD ：只从数据源加载数据，不读取缓存中的数据，也不写入缓存。

另外在@Cache中只能静态指写缓存操作类型，如果想在运行时调整操作类型，需要通过CacheHelper.setCacheOpType()方法来进行调整。

9. 批量删除缓存

在很多时候，数据查询条件是比较复杂，我们无法获取或还原要删除的缓存key。

AutoLoadCache 为了解决这个问题，使用Redis的hash表来管理这部分的缓存。把需要批量删除的缓存放在同一个hash表中，如果需要需要批量删除这些缓存时，直接把这个hash表删除即可。这时只要设计合理粒度的缓存key即可。

通过@Cache的hfield设置hash表的key。

我们举个商品评论的场景（代码五）：

public interface ProuductCommentMapper {
    @Cache(expire=600, key="'prouduct_comment_list_'+#args[0]", hfield = "#args[1]+'_'+#args[2]")
    // 例如：prouductId=1, pageNo=2, pageSize=3 时相当于Redis命令：HSET prouduct_comment_list_1 2_3  List<Long>
    public List<Long> getCommentListByProuductId(Long prouductId, int pageNo, int pageSize);
        
    @CacheDelete({@CacheDeleteKey(value="'prouduct_comment_list_'+#args[0].prouductId")}) 
    // 例如：#args[0].prouductId = 1时，相当于Redis命令: DEL prouduct_comment_list_1
    public void addComment(ProuductComment comment) ;
    
}

如果添加评论时，我们只需要主动删除前3页的评论（代码六）：

public interface ProuductCommentMapper {
    @Cache(expire=600, key="'prouduct_comment_list_'+#args[0]+'_'+#args[1]", hfield = "#args[2]")
    public List<Long> getCommentListByProuductId(Long prouductId, int pageNo, int pageSize);
        
    @CacheDelete({
        @CacheDeleteKey(value="'prouduct_comment_list_'+#args[0].prouductId+'_1'"),
        @CacheDeleteKey(value="'prouduct_comment_list_'+#args[0].prouductId+'_2'"),
        @CacheDeleteKey(value="'prouduct_comment_list_'+#args[0].prouductId+'_3'")
    }) 
    public void addComment(ProuductComment comment) ;
    
}

10. 双写不一致问题

在“代码二”中使用updateUser方法更新用户信息时，同时会主动删除缓存中的数据。如果在事务还没提交之前又有一个请求去加载用户数据，这时就会把数据库中旧数据缓存起来，在下次主动删除缓存或缓存过期之前的这一段时间内，缓存中的数据与数据库中的数据是不一致的。AutoloadCache框架为了解决这个问题，引入了一个新的注解：@CacheDeleteTransactional （代码七）:

public UserServiceImpl implements UserService {
    
    @Autowired
    private UserMapper userMapper;
    
    public User getUserById(Long userId) {
        return userMapper.getUserById(userId);
    }
    @Transactional(rollbackFor=Throwable.class)
    @CacheDeleteTransactional
    public void updateUser(User user) {
        userMapper.updateUser(user); 
    }
}

使用@CacheDeleteTransactional注解后，AutoloadCache 会先使用ThreadLocal缓存要删除缓存KEY，等事务提交后再去执行缓存删除操作。其实不能说是“解决不一致问题”，而是缓解而已。

缓存数据双写不一致的问题是很难解决的，即使我们只用数据库（单写的情况）也会存在数据不一致的情况（当从数据库中取数据时，同时又被更新了），我们只能是减少不一致情况的发生。对于一些比较重要的数据，我们不能直接使用缓存中的数据进行计算并回写的数据库中，比如扣库存，需要对数据增加版本信息，并通过乐观锁等技术来避免数据不一致问题。

11. 与Spring Cache的比较

AutoLoadCache 的思想其实是源自 Spring Cache，都是使用 AOP + Annotation ，将缓存与业务逻辑进行解耦。区别在于：

AutoLoadCache 的AOP不限于Spring 中的AOP技术，即可以脱离Spring 生态使用，比如成功案例nutz；
Spring Cache不支持命名空间；
Spring Cache没有自动加载、异步刷新、拿来主义机制；
Spring Cache使用name 和 key的来管理缓存（即通过name和key就可以操作具体缓存了），而AutoLoadCache 使用的是namespace + key + hfield 来管理缓存，同时每个缓存都可以指定缓存时间（expire）。也就是说Spring Cache 比较适合用来管理Ehcache的缓存，而AutoLoadCache 更加适合管理Redis, Memcache，尤其是Redis，hfield 相关的功能都是针对它们进行开发的（因为Memcache不支持hash表，所以没办法使用hfield相关的功能）。
Spring Cache不能针对每个缓存Key，进行设置缓存过期时间。而在缓存管理应用中，不同的缓存其缓存时间要尽量设置为不同的。如果都相同的，那缓存同时失效的可能性会比较大些，这样穿透到数据库的可能性也就更大了，对系统的稳定性是没有好处的；
Spring Cache 最大的缺点就是无法使用Spring EL表达式来动态生成Cache name,而且Cache name是的必须在Spring 配置时指定几个，非常不方便使用。尤其想在Redis中想精确清除一批缓存，是无法实现的，可能会误删除我们不希望被删除的缓存；
Spring Cache只能基于Spring 中的AOP及Spring EL表达式来使用，而AutoloadCache 可以根据使用者的实际情况进行扩展；
AutoLoadCache中使用@CacheDeleteTransactional 来减少双写不一致问题，而Spring Cache没有相应的解决方案；

最后欢迎大家到github对AutoLoadCache开源项目Star和Fork进行支持。

面对缓存，有哪些问题需要思考？

1. 如何将业务逻辑与缓存之间进行解耦？

2. 对缓存进行“包装”

3. 如何提升缓存key生成表达式性能？

4. 如何解决缓存Key冲突问题？

5. 压缩缓存数据及提升序列化与反序列化性能

6. 如何减少回源并发数？

7. 异步刷新

8. 支持多种缓存操作

9. 批量删除缓存

10. 双写不一致问题

11. 与Spring Cache的比较

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

程序员

@IT·互联网