redis的主动更新策略解释

102 阅读2分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 11 天,点击查看活动详情

前言

在上一篇文章中我们了解了redis缓存的策略,三种随各有优劣。但是在大多数情况下是使用的主动更新策略。所以今天这篇文章讲的就是主动更新中涉及的一些问题。

问题1删除缓存还是更新缓存

在数据库的数据发生变化之后,主动更新的策略是通知缓存也发生相应的变化。但我当时并没有把这个变化说明白,是删除缓存还是直接把缓存也进行对应的更新。这里的答案是前者。具体原因如下,如果我们选择直接更新缓存的话,那万一这个对应的缓存资源在长时间都没有使用的话,不就造成了浪费了吗。除此之外,数据库频繁发生修改的话,缓存也进行大量的修改,无效读写过多。

如何保证缓存与数据库的操作同时成功

如果是单体系统设置事务即可,但如果是分布式的话就看这篇文章即可(笔者没怎么接触过[)]((分布式事务解决方案--TCC)

在问题一的基础上,是先删除缓存还是先更新数据库

这里面的先后问题都会造成不一样的结果。现在有两个线程同时请求。假设我们使用先删除缓存然后更新数据库的策略可能会有这个情况发生。线程1在删除缓存之后,还没来得及写入数据库,线程2看到没有缓存于是就去数据库拿到没有修改的值(数据库读比写操作快),之后第所有线程看到缓存里面有所以直接拿,这就会造成后面永远受这个值。而现在使用先更新数据库然后删除缓存,同样是两个线程,线程一在更新数据库时,线程2去缓存里面拿数据,拿到旧值,但是线程2拿完之后,更新数据库完成,后面的线程就全都拿到正确的值。

总结

虽然都会发生错误。但显然是后者会出现错误的代价较小,所以对于主动更新来说是需要先更新数据库然后删除缓存的。