黑马点评项目-6.查询商铺的Redis缓存实现

最新推荐文章于 2024-09-30 11:23:38 发布

Jayvee1659

最新推荐文章于 2024-09-30 11:23:38 发布

阅读量593

点赞数 10

分类专栏：黑马点评文章标签：缓存 redis 数据库

本文链接：https://blog.csdn.net/GrandpaLee/article/details/140751460

版权

黑马点评专栏收录该内容

7 篇文章 0 订阅

订阅专栏

查询商铺的Redis缓存实现

缓存架构图

缓存更新

缓存更新策略

	内存淘汰	超时剔除	主动更新
说明	Redis数据库自动维护，内存不足自动淘汰部分数据，下次查询时更新缓存。	给缓存数据添加TTL时间，到期后自动删除数据。	编写业务逻辑，在修改数据库的同时，更新缓存。
一致性	差（内存充足时，缓存长时间不更新）	一般（与TTL相关，TTL太长则长期不更新）	好（根据业务设定更新逻辑）
维护成本	低（Redis自带）	低（只需要存数据的时候设定TTL）	高（需要成需要编写更新逻辑）

缓存策略的选择：
- 低一致性需求：使用内存淘汰机制，例如店铺类型的查询缓存（店铺类型不会经常发生变化）
- 高一一致性需求：使用主动更新策略+超时剔除（兜底）。例如店铺详情查询的缓存（店铺介绍等信息经常发生变化。

主动更新策略

Cache Aside Pattern（人工编码）：由缓存的调用者，在更新数据库的同时更新缓存。（实现复杂）
Read/Write Through Pattern（整合服务）：缓存和数据库整合为一个服务，由服务来维护一致性。向调用者提供服务接口。（实现困难，市面上无现成的方案）
Write Behind Caching Pattern（写回）：调用者只操作缓存（与方式2的区别），由其他线程异步地将缓存数据持久化到数据库，保证最终的一致性。即开启一个守护线程，定时查询缓存和数据库中是否存在不一致，发生不一致就将缓存中的数据更新到数据库中。（一致性和可靠性存在一定问题，如果缓存更新了，但守护线程尚未查询到变化，此时数据是不一致的。当缓存宕机时，数据丢失。）

一般情况下，方式1使用较多。

Cache Aside Pattern（人工编码）

思考
- 删除缓存还是更新缓存？
  更新缓存：更新数据库的时候，重写缓存，无效写操作较多（用户不查询时，也有大量的写缓存操作）。
  删除缓存：等到下一次查询再更新缓存。
- 如何保证缓存与数据库的操作同时成功或失败（原子性）？
  单体系统：将缓存与数据库操作放在一个事务。
  分布式系统：利用TTC等分布式事务方案。
- 先操作缓存还是先操作数据库？（一般都可以）
先操作缓存和先操作数据库的区别
如果由两个线程A,B，此时Cache中存在值：10，数据库中存在值：10。
- 先操作缓存的问题：A线程准备更新数据为20。A线程先删除缓存，删除结束后，还未更新数据库，此时B线程查询缓存，发现未命中，则直接查询数据库并写入缓存。B线程结束后，A线程更新数据库的值为20。此时，Cache中存在值：10，数据库中却为20。发生了数据不一致。（发生的可能性大，因为删缓存操作执行速度快，写数据库操作慢，可能数据库写操作速度慢。）
- 先操作数据库的问题：某个情况，缓存失效了。此时，线程A查询缓存未命中，查询数据库得到值10准备写入缓存。此时，线程B更新数据库的值为20，删除缓存（此时缓存不存在，删除未进行实际操作）。线程B结束后，A线程写入缓存值10。此时Cache值为10，数据库为20。发生数据不一致。（可能性小，因为写缓存的速度挺快的，A写入缓存后，线程B的删除操作会实际发生，下次查询还是一致的。）