总结
谈到面试，其实说白了就是刷题刷题刷题，天天作死的刷。。。。。
为了准备这个“金三银四”的春招，狂刷一个月的题，狂补超多的漏洞知识，像这次美团面试问的算法、数据库、Redis、设计模式等这些题目都是我刷到过的
并且我也将自己刷的题全部整理成了PDF或者Word文档（含详细答案解析）
66个Java面试知识点
架构专题（MySQL，Java，Redis，线程，并发，设计模式，Nginx，Linux，框架，微服务等）+大厂面试题详解（百度，阿里，腾讯，华为，迅雷，网易，中兴，北京中软等）
算法刷题（PDF）
更新还是删除是个问题
==========
当MySQL被更新时，我们如何处理Redis中的老数据呢？
江湖上有两种常见的做法，我们一起来看看：
-
删除操作 ：直接将key淘汰掉，是否再次被加载由后续读请求决定，本次只负责删除，只管杀不管埋。
-
更新操作 ：直接update发生变化的key，相当于帮后面的请求做了加载的操作，管杀管埋。
可以明确一点删除操作直接操作就行，但是更新操作可能涉及的处理步骤更多，也就是update比delete更复杂。
还有一点，我们需要尽量保证Redis中的数据都是热数据，update每次都会使得数据驻留在Redis中，或许这是没有必要的，因为这些可能是冷数据，至于要加载哪些数据，还是交给后面的请求比较合适。
综上，我们更倾向于将delete操作作为通用的选择，因此文章后续都是基于删除缓存的策略来展开的。
如何解决不一致问题
=========
Redis和MySQL的数据不一致产生的根源是: 业务进行更新/写入操作 。
先操作Redis 还是 先操作MySQL是个问题，操作时序不同产生的影响也不同。
尺有所短，寸有所长，说到底是一种权衡，哪一种组合产生的负面影响对业务最小，就倾向于哪种方案。
缓存系统的数据不一致问题，是个经典的问题，因此肯定有很多解决问题的套路，所以让我们带着分析和思考去看看，各个方案的利弊。
思路一：设置缓存过期时间
============
当向Redis写入一条数据时，同时设置过期时间x秒，业务不同过期时间不同。
过期时间到达时Redis就会删掉这条数据，后续读请求Redis出现Cache Miss，进而读取MySQL，然后把数据写到Redis。
如果发生更新操作时，只操作MySQL，那么Redis中的数据更新就只是依赖于过期时间来保底。
换句话说： 如果某个key的数据目前在缓存中，当数据发生更新时，只写MySQL并不写Redis，在更新数据后且缓存过期前的这段时间内，读取的数据是不一致的。
画外音：这种方案是最简单的，如果业务对短时间不一致问题并不在意，设置过期时间的方案就足够了，没有必要搞太复杂。
思路二：先淘汰缓存&再更新主存
===============
为了防止其他线程读到缓存中的旧数据，干脆淘汰掉，然后把数据更新到主存储，后续的请求再次读取时触发Cache Miss，从而读取MySQL再将新数据更新到Redis。
-
在T1时刻：Redis和MySQL对于age的值都是18，二者一致;
-
在T2时刻：有更新请求需要设置age=20，此时Redis中就没有age这个数据了；在完成Redis淘汰后，进行MySQL数据更新age=20;
这个方案听着还不错的样子，但是读写请求都是并发的，先后顺序完全无法预测，甚至后发出的请求先处理完成，也是很常见的。
因此就造成一个明显的漏洞： 在淘汰Redis的数据完成后，更新MySQL完成之前，这个时间段内如果有新的读请求过来，发现Cache Miss了，就会把旧数据重新写到Redis中，再次造成不一致，并且毫无察觉后续读的都是旧数据。
画外音：这个方案其实不能说完全没有用，但是至少不完美吧，还可以再想想别的方案。
思路三：先更新主存&再淘汰缓存
===============
先更新MySQL，成功之后淘汰缓存，后续读取请求时触发Cache Miss再将新数据回写Redis。
这种模式在更新MySQL和淘汰Redis这段时间内，请求读取的还是Redis的旧数据，不过等MySQL更新完成，就可以立刻恢复一致，影响相对比较小。
但是，假如T0时刻读取的数据在缓存没有，那么触发Cache Miss后会产生回写，假如这个回写动作是在T4时刻完成，那么写入的还是老数据，如图：
这种情况确实有问题，但是真是好巧不巧：
-
事件A：更新MySQL前出现一个读请求，且缓存中无数据出现cache miss
-
事件B：T3时刻回写Redis的操作才完成，在此之前T2时刻清除了缓存
那么发生问题的概率就是P(A)*P(B)，从实际考虑这种综合事件发生的概率非常低，因为写操作远慢于读操作。
也就是实际场景中上图中更新MySQL&淘汰缓存的操作耗时更久，可以把之前回写到Redis老数据给清除掉。
画外音：先更新MySQL再淘汰Redis的方案，虽然存在小概率不一致问题，但是总体来说工程上是可用的，比如非要说写完MySQL挂了，Redis就没淘汰，这种情况只能说确实有问题。
思路四：延时双删策略
==========
前面提到的思路二和思路三都只有一次Redis淘汰操作，这里要说的延时双删本质上是思路二和思路三的结合：
说实话个人觉得，这个方案有点堆操作的感觉，而且设置延时的目的是为了避免思路三的小概率问题，延时设置多久不好确定，二来延时降低了并发性能，同时前置的删除缓存操作起到的作用并不大。
这个方案倒是透露出一种思想：多删几次，可能一致性更有保证，那确实如此。
画外音：这个方案也不是说不行，其实有点麻烦，并且在复杂高并发场景中反而影响性能，要是一般的场景或许也能用起来。
思路五：异步更新缓存
==========
既然直接操作MySQL和Redis都多少存在一些问题，那么能不能引入中间层来解决问题呢？
把MySQL的更新操作完成后不直接操作Redis，而是把这个操作命令(消息)扔到一个中间层，然后由Redis自己来消费更新数据，这是一种解耦的异步方案。
单纯为了更新缓存引入中间件确实有些复杂，但是像MySQL提供了binlog的同步机制，此时Redis就作为Slave进行主从同步，实现数据的更新，成本也还可以接受。
画外音：引入中间层思想真是万金油啊！
总结一下
2021年Java中高级面试必备知识点总结
在这个部分总结了2019年到目前为止Java常见面试问题，取其面试核心编写成这份文档笔记，从中分析面试官的心理，摸清面试官的“套路”，可以说搞定90%以上的Java中高级面试没一点难度。
本节总结的内容涵盖了：消息队列、Redis缓存、分库分表、读写分离、设计高并发系统、分布式系统、高可用系统、SpringCloud微服务架构等一系列互联网主流高级技术的知识点。
目录：
（上述只是一个整体目录大纲，每个点里面都有如下所示的详细内容，从面试问题——分析面试官心理——剖析面试题——完美解答的一个过程）
部分内容：
对于每一个做技术的来说，学习是不能停止的，小编把2019年到目前为止Java的核心知识提炼出来了，无论你现在是处于什么阶段，如你所见，这份文档的内容无论是对于你找面试工作还是提升技术广度深度都是完美的。
不想被后浪淘汰的话，赶紧搞起来吧，高清完整版一共是888页，需要的话可以点赞+关注
完美的。
不想被后浪淘汰的话，赶紧搞起来吧，高清完整版一共是888页，需要的话可以点赞+关注
扫一扫
6075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
