缓存的设计方式

问题情况：

当有大量的请求到内部系统时，若每一个请求都需要我们操作数据库，例如查询操作，那么对于那种数据基本不怎么变动的数据来说，每一次都去数据库里面查询，是很消耗我们的性能

尤其是对于在海量数据中进行数据操作的时候，如果都是从 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 的操作时，自然是写入的操作是要后返回结果的，此处不要杠啥读写数据量不一致的情况，咱们做对比，自然是在同等条件下比较咯