redis实战-添加商户缓存

最新推荐文章于 2024-09-26 17:06:13 发布

小白要code

最新推荐文章于 2024-09-26 17:06:13 发布

阅读量792

点赞数 30

分类专栏： redis JAVA 文章标签：缓存 redis

本文链接：https://blog.csdn.net/weixin_45628042/article/details/140068730

版权

39 篇文章 0 订阅

订阅专栏

5 篇文章 0 订阅

订阅专栏

先从Redis中查询，如果没有查到，再去MySQL中查询，同时查询完毕之后，将查询到的数据也存入Redis，这样当下一个用户来进行查询的时候，就可以直接从Redis中获取到数据
在这里插入图片描述

缓存更新是Redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们想Redis插入太多数据，此时就可能会导致缓存中数据过多，所以Redis会对部分数据进行更新，或者把它成为淘汰更合适

由于我们的缓存数据源来自数据库，而数据库的数据是会发生变化的，因此，如果当数据库中数据发生变化，而缓存却没有同步，此时就会有一致性问题存在，其后果是

那么如何解决这个问题呢？有如下三种方式

Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库之后再去更新缓存，也称之为双写方案（主要方案）
Read/Write Through Pattern：缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。但是维护这样一个服务很复杂，市面上也不容易找到这样的一个现成的服务，开发成本高
Write Behind Caching Pattern：调用者只操作缓存，其他线程去异步处理数据库，最终实现一致性。但是维护这样的一个异步的任务很复杂，需要实时监控缓存中的数据更新，其他线程去异步更新数据库也可能不太及时，而且缓存服务器如果宕机，那么缓存的数据也就丢失了

综上所述，在企业的实际应用中，还是方案一最可靠，但是方案一的调用者该如何处理呢？

在这里插入图片描述
三个问题：
1. 删除缓存还是更新缓存？
2. 如何保证缓存与数据库的操作同时成功或者失败？
3. 先操作缓存还是先操作数据库？

如果采用方案一，假设我们每次操作完数据库之后，都去更新一下缓存，但是如果中间并没有人查询数据，那么这个更新动作只有最后一次是有效的，中间的更新动作意义不大，所以我们可以把缓存直接删除，等到有人再次查询时，再将缓存中的数据加载出来
对比删除缓存与更新缓存
更新缓存：每次更新数据库都需要更新缓存，无效写操作较多
删除缓存：更新数据库时让缓存失效，再次查询时更新缓存

我们来仔细分析一下这两种方式的线程安全问题
先删除缓存，再操作数据库
删除缓存的操作很快，但是更新数据库的操作相对较慢，如果此时有一个线程2刚好进来查询缓存，由于我们刚刚才删除缓存，所以线程2需要查询数据库，并写入缓存，但是我们更新数据库的操作还未完成，所以线程2查询到的数据是脏数据，出现线程安全问题
先操作数据库，再删除缓存
线程1在查询缓存的时候，缓存TTL刚好失效，需要查询数据库并写入缓存，这个操作耗时相对较短（相比较于上图来说），但是就在这么短的时间内，线程2进来了，更新数据库，删除缓存，但是线程1虽然查询完了数据（更新前的旧数据），但是还没来得及写入缓存，所以线程2的更新数据库与删除缓存，并没有影响到线程1的查询旧数据，写入缓存，造成线程安全问题

虽然这二者都存在线程安全问题，但是相对来说，后者出现线程安全问题的概率相对较低，所以我们最终采用后者先操作数据库，再删除缓存的方案