redis缓存的几种模式以及读写缓存的几种模式

我们先来总结一下redis的读写缓存模式，3种模式

Cache Aside Pattern(旁路缓存模式)
常用的一个缓存模式，适合读请求比较多的场景，同时维持缓存和数据库，以数据库结果为准
读过程: 先从缓存中读数据，读不到的话从数据库中找数据，然后把数据库读到的数据放入缓存
写过程:先更新数据库，后删除cache
常见的面试问题:写数据的过程，可以先删除缓存，然后更新数据库吗？
答案是不可以，数据会出现不一致的情况
为什么不让写完的数据写入到缓存中呢？
比如现在有A B，A要读数据B要写数据，缓存中没有数据，这时A数据要从数据库中读数据，读完数据准备放入数据库，然后这时B发出写请求，写入数据到数据库然后更新之后，设置了缓存失效，然后A这时候再读数据的话就是旧数据，产生了脏数据。

那我们可以先更新数据库，后删除缓存吗？
也会出现不一致的问题，不过可能性小，因为缓存的写入比数据库的写入快。

Read/Write Though Pattern(读写穿透模式)
读写穿透模式把缓存作为主要存储，负责将数据读取和写入到数据库中，开发少见，一方面是性能问题，另一面是redis并没有提供cache把数据写入到数据库。
读过程:从缓存中读取数据，读取到直接返回，读取不到的话，先从数据库加载，然后写入到缓存之后响应。
写过程:先查缓存，缓存中不存在直接更新数据库，如果缓存中存在，先更新缓存，然后缓存更新到数据库
出现脏数据效率较低，依赖缓存

Write Behind Pattern (异步缓存写入)
跟读写穿透很像，都是缓存把数据读取写入到数据库中，读写穿透是同步更新缓存和数据库，异步缓存是只更新缓存不直接更新数据库，而是异步批量的方式更新数据库。
应用场景:消息队列中消息异步写入磁盘，写性能很高，适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量，点赞量。但是数据一致性较差，有数据丢失的可能。

然后来说一下redis缓存的几种模式:
缓存雪崩:缓存集中在同一段时间失效，所有的查询都掉到了数据库的头上，会对数据库，cpu造成很大的压力，严重的会导致数据库宕机。
解决方法:

设置不同的过期时间，缓存失效的时间尽量均匀
设置双层缓存策略:A1为原始缓存，A2为复制缓存，A2设置长期，A1设置短期，A1失效时访问A2
定时更新缓存策略:时效性要求不高的缓存，进行初始化，采用定时任务或者移除缓存
数据预热：把热点数据放入缓存中，先更新缓存，避免查询数据库，后缓存的问题。
缓存击穿:大量的请求去查询一个key，然后key失效了，导致大量请求去找数据库
解决方法:第一个查询数据的请求加一个互斥锁，然后请求之后，把数据放入缓存，再有这个请求，直接走缓存

缓存穿透:用户查询数据，数据库没有，缓存肯定也没有，导致用户查询的时候，缓存中找不到对应的值，然后去查询数据库，每次都要查询数据库，然后返回是null值，绕过了缓存直接查数据库
解决方法:把null值缓存
或者采用布隆过滤器BloomFilter:将所有的数据放入一个足够大的集合中，不存在的数据会被集合拦截掉，缓存前加一个BloomFilter，查询的时候，先查询key是否存在，不存在直接返回，存在先查询缓存后查询数据库。

redis缓存的几种模式以及读写缓存的几种模式插图