问题情况：
当有大量的请求到内部系统时，若每一个请求都需要我们操作数据库，例如查询操作，那么对于那种数据基本不怎么变动的数据来说，每一次都去数据库里面查询，是很消耗我们的性能
尤其是对于在海量数据中进行数据操作的时候，如果都是从 DB 中进行加载，那这是在挑战用户的耐性
简单来看，例如我们要去小区里面了解一个人在不在家，当没有通讯工具的前提下，我们每一次都要经过小区们的保安，然后再到具体的单元楼，最终到了这家门口，最终才知道在不在家
如果我们换了一个比较优秀的保安，他知道当前小区里面的特定的家里面是否有人，那这个时候，如果我们直接去问小区保安，自然就无需跑冤枉路了，自然就提高了效率
此处简单的就可以将优秀保安看做是一个缓存，我们每一次去访问，就会先去访问缓存 ， 这样就能极大的提高访问效率和系统性能
可以看出，有一个优秀的保安相当重要
缓存的基本设计方式是什么样的
设计缓存自然也是为了解决系统是的低效问题，让系统可以高性能，高并发
例如我们直接访问单机的数据库如mysql 也就是上千级别的 qps，如果是访问 缓存的时候，就能达到上万，上十几万，这差距不是一点半点，是一个质的飞越
缓存的设计实际上就是 DB 和 缓存操作顺序以及谁来操作的事情，大体分为如下 4 种模式
- Cache Aside
- Read Through
- Write Through
- Write Behind Caching
上述四种模式， Cache Aside 用的方式是最常使用的，咱们后续细说
后续三种模式的含义是
Read Through
- 是在查询操作的时候更新缓存，若缓存失效了，则是由缓存服务器自己将数据加载到缓存中
Write Through
- 是在更新数据库的时候，如果命中了缓存，则先更新缓存，再由缓存服务器自己去更新数据，
- 如果是没有命中缓存，那么就直接更新数据库
Write Behind Caching 通过名字我们知道，是在写到缓存操作之后才做些操作，实际上这种模式只更新缓存，不会更新数据库，缓存服务器会以异步的方式将数据批量更新到数据库中
很明显，这种，模式速度自然会更快，可这种模式对于保证数据库和缓存数据一致性问题，是个硬伤，且还会存在丢数据的情况，比如，咱们的缓存服务器挂掉了
Cache Aside 读写缓存模式是怎么玩的
Cache Aside 读写模式缓存又是如何去处理的呢，一起来看看
Cache Aside 模式读取数据的逻辑是这个样子的：
读取数据时
- 先读取缓存中的数据，如果缓存中有数据，则直接返回
- 若缓存中没有数据，则去读数据库中的数据，并将数据同步到缓存中
写入数据时
- 写入数据库，写入成功时，将缓存的数据删除掉
仔细的同学可能会思考并提出这样的问题，如果我一个查询操作，现在缓存中无数据，此时会去数据库中查询，在这个过程中，另外有一个写入数据库的操作，且操作完毕后，删除了缓存，这个时候，第一个操作实际上从数据库拿到的还是之前的老数据，并且会将数据放到缓存中，那么此时的数据实际上是一个老数据，也可以理解是在脏数据
这个点其实我们就无需担心了，大佬们已经论证过这种情况出现的概率极低
因为咱们的写表操作是要锁表的，且我们知道数据库写入操作比读取操作要慢，也就是说，当同时有一个读取和写入 DB 的操作时，自然是写入的操作是要后返回结果的，此处不要杠啥读写数据量不一致的情况，咱们做对比，自然是在同等条件下比较咯
从图中我们知道，同等条件下，先进行查询 DB 的操作，过程中，来了一个写入 DB 操作，自然是 查询操作先返回，写入操作再返回结果
其实此处，有的做法是，写入数据的时候，写入成功，同时也会将数据同步到缓存中
那么这种方式的引入，实际上从数据库到缓存就有了 2 种情况了，一个是查询操作，一个是写入操作，那么在实际操作中，我是可以加入分布式锁来进行处理，保证写入数据库的时候，同时也要写入缓存，数据才可访问，当然查询 DB 操作也是一样
缓存带来了哪些问题？
那么引入缓存除了可以带来高性能，高并发，自然也是有会带来一些问题的，例如：
- 缓存击穿
- 缓存穿透
- 缓存雪崩
如上 3 中情况，都是由于缓存这一层防线失守了，导致外部请求以各种各样的形式，各种各样的原因打到了数据库上，导致出现的问题，详细的 缓存击穿，缓存穿透，缓存雪崩的出现情况，解决方式可以查看历史文章 redis 缓存穿透，缓存击穿，缓存雪崩
感谢阅读，欢迎交流，点个赞，关注一波 再走吧
可以进入地址进行体验和学习：https://xxetb.xet.tech/s/3lucCI
