缓存的设计方式

2,632 阅读5分钟

问题情况:

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

尤其是对于在海量数据中进行数据操作的时候,如果都是从 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 缓存穿透,缓存击穿,缓存雪崩

感谢阅读,欢迎交流,点个赞,关注一波 再走吧

我正在参与掘金技术社区创作者签约计划招募活动,点击链接报名投稿