-
线程1查询缓存，由于缓存失效，所以查询数据库。
-
此时线程2突然要更新数据库，将数据改为20。
-
此时线程2删除缓存，由于缓存中没有数据，因此删了个寂寞😂😂😂
-
这时线程1再把数据写入缓存，此时写入缓存的数据是10。这就造成了缓存和数据库中的数据不一样，缓存中的数据为10，数据库中的数据为20。
虽然第二种情况会造成缓存和数据库中的数据不一样，但是这种情况发生的概率是微乎其微的。
因为写入缓存的速度是要快于更新数据库操作的，所以线程1查询数据库后，几乎不会等线程2更新数据库完数据库后再写入缓存。并且这种情况还要在缓存失效的前提下才能发生，所以第二种在整体上胜出第一种。
因此还是先操作数据库再操作缓存比较合适
🚕Read/Write Through Pattern
Read Through 模式就是在查询操作中更新缓存，也就是说，当缓存失效的时候，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载。
Write Through 模式和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后由缓存自己更新数据库（这是一个同步操作）。
🚕Write Behind Caching Pattern
Write Behind Caching 更新模式就是在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是直接操作内存速度快。因为异步，Write Behind Caching 更新模式还可以合并对同一个数据的多次操作到数据库，所以性能的提高是相当可观的。
但其带来的问题是，数据不是强一致性的，而且可能会丢失。另外，Write Behind Caching 更新模式实现逻辑比较复杂，因为它需要确认有哪些数据是被更新了的，哪些数据需要刷到持久层上。只有在缓存需要失效的时候，才会把它真正持久起来。
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，所以不能从缓存上面取到客户端想要的数据，并且这些请求都会打到数据库上，导致数据库短时间内承受大量的请求而崩溃
而解决缓存穿透的方案通常有两种：
1.缓存空对象
从缓存上取不到数据，在数据库中也取不到，这时可以把key-value键值对写成key-null键值对，并且设置有效时间（设置短一些）。这样可以防止带有恶意的用户频繁地用一个值来攻击数据库。
优点：实现简单，便于维护
缺点：需要消耗额外的内存；
并且可能造成短期的不一致
2.布隆过滤器
过滤器，顾名思义，就是不让某些请求通过，不放行某些恶意的请求。
在缓存中，采用布隆过滤器，将可能存在的数据哈希到足够大的bitmap上，如果客户端请求的数据不存在，布隆过滤器会拒绝客户端的请求，如果存在则会放行请求，再去查询缓存，按步骤执行后面的操作。
缓存雪崩是指在同一时间段内大量的缓存key同时失效或者Redis服务器宕机，导致大量的请求到达数据库，给数据库带来巨大的压力而使得数据库崩掉。
缓存雪崩的解决方案有以下几种：
1.给不同的Key的TTL值添加随机值（如1-5分钟随机），防止同一时间段内大量数据发生过期的现象。
2.不给缓存设置失效时间，让它永久有效
3.利用Redis集群提高服务的可用性。将热点的key放到不同的节点上。
4.可以考虑加锁（最多使用）或者队列的方式来保证不会有大量的线程对数据库一次性读写，从而避免了key失效时大量的并发请求落到存储系统上。
缓存击穿问题也叫热点Key问题，是一个被高并发访问并且缓存创建业务较复杂的key突然失效了，缓存中没有数据但数据库中有数据，并发用户无数的请求访问读缓存不能读到数据，又同时去数据库里查询数据，这无数的请求会瞬间给数据库带来巨大的冲击导致数据库压力过大。
缓存击穿和缓存雪崩很相似，但不同的是，缓存击穿是指客户端并发查同一条数据，缓存雪崩是指不同的数据都过期了，很多数据都查不到而去数据库中查询。
解决方案：
1.加互斥锁
加互斥锁只允许一个线程重建缓存，其他线程等待上锁的线程重建缓存步骤执行完，释放锁后，其他线程再重新从缓存上获取数据。
优点：
**没有额外的内存消耗；
保证了一致性；
实现起来比较简单**
缺点：
**线程需要等待，性能受到影响；
还可能出现死锁的风险**
2.逻辑过期
给每个value设置一个过期时间，当发现超过逻辑过期时间后，会使用单独的线程去更新缓存。
但从缓存层面上来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
优点：
线程无须等待，性能较好
缺点：
**不能保证一致性；
有额外的内存消耗；
实现起来比较复杂**
=========================================================================
首先需要了解什么是持久化。持久化就是把内存中的数据写到磁盘中去，防止服务器宕机造成内存中的数据丢失。
redis持久化的方式有两种，一种是RDB持久化，一种是AOF持久化。
RDB全称Redis Database Backup file（Redis数据备份文件） 也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。
Redis停机时会执行一次RDB。
Redis内部有触发RDB的机制，它的命令举例如下：
save命令
Reids save命令执行一个同步保存操作，将当前Redis实例的所有数据快照(snapshort)已RDB文件的方式保存到磁盘
bgsave命令
bgsave执行后，会立刻返回OK，Redis 会fork一个子进程，原来的redis主进程继续执行后续操作，新fork的子进程负责将数据保存到磁盘，然后退出
save 900 1 表示900秒内，如果有至少一个key被修改，则执行bgsave
如果是 save " ",表示禁用RDB
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。
fork采用的是copy-on-write技术：
当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。
RDB方式bgsave的基本流程：
1.fork主进程得到一个子进程，共享内存空间
2.子进程读取内存数据并写入新的RDB文件
3.用新RDB文件替换旧的RDB文件。
RDB方式的优缺点
优点：
（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
（2）RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点：
（1）如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据。
（2）fork子进程、压缩、写出RDB文件都比较耗时。RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。当重启Redis时会重新将持久化的日志中文件恢复数据。
由于AOF记录的是命令，所以AOF文件比RDB文件大得多。并且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。
如：
set num Tom；
set name Jack；
set name Lucy；
最后记录的name是Lucy
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
分享
这次面试我也做了一些总结，确实还有很多要学的东西。相关面试题也做了整理，可以分享给大家，了解一下面试真题，想进大厂的或者想跳槽的小伙伴不妨好好利用时间来学习。学习的脚步一定不能停止！
Spring Cloud实战
Spring Boot实战
面试题整理（性能优化+微服务+并发编程+开源框架+分布式）
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
(img-BAm204fc-1712664490684)]
Spring Cloud实战
[外链图片转存中…(img-ZJ34uXrG-1712664490684)]
Spring Boot实战
[外链图片转存中…(img-18DnFeNw-1712664490684)]
面试题整理（性能优化+微服务+并发编程+开源框架+分布式）
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-Q5E7Twu3-1712664490685)]
扫一扫
1680
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
