中国外贸出口网站,免费的郑州网络推广服务,北京网站建设网,网站建设报价 下载1 缓存和数据库的数据一致性分析
1.1 Redis 中如何保证缓存和数据库双写时的数据一致性#xff1f; 无论先操作db还是cache#xff0c;都会有各自的问题#xff0c;根本原因是cache和db的更新不是一个原子操作#xff0c;因此总会有不一致的问题。想要彻底解决这种问题必须…
1 缓存和数据库的数据一致性分析
1.1 Redis 中如何保证缓存和数据库双写时的数据一致性 无论先操作db还是cache都会有各自的问题根本原因是cache和db的更新不是一个原子操作因此总会有不一致的问题。想要彻底解决这种问题必须将cache和db的更新操作归在一个事务之下例如使用一些分布式事务或者强一致性的分布式协议。或者采用串行化可以保证强一致性。 1.1.1 写请求为什么更新数据库后是删除缓存而不是更新缓存 注意看上面的图片当有两个写请求的线程线程一比线程二先执行反而是线程二先执行完。这时候缓存保存的是A的数据老数据数据库保存的是B的数据新数据数据不一致了。
1.1.2 写请求时为什么更新数据库然后再删除缓存 如果采用写请求先删除缓存再更新数据库就会出现如上图的情况线程B读到的是老的数据并且缓存中也保存的是老的数据。
1.1.3 写请求时先更新数据后删除缓存一定没有问题吗 可以看到一个读请求和一个写请求读请求可能会读取到旧的数据或者当写请求删除缓存失败读请求会一直读取的是旧的缓存数据。只不过是这种情况相对于其他的实现方式概率要低很多。
1.2 三种方案保证数据库与缓存的一致性
1.2.1 缓存延时双删 第二次删除缓存一般会采用延时的操作主要是用来删除读请求产生的缓存数据
1.2.2 删除缓存重试机制 延时双删和普通写操作的删除操作都有可能会操作失败导致数据不一致删除重试机制就是为了保证删除可靠性。删除失败的key放到消息队列中这种机制会造成大量的业务代码入侵。
1.2.3 读取biglog异步删除缓存 通过binlog日志将要删除的key发送到消息队列中。
1.3 如何使用 Redis 做异步队列和延时队列
1.3.1 延时队列 将需要延时执行的任务放到 Redis 中的 Zset 类型中Zset会根据 score 自动进行数据排序score使用时间戳定义一个延时任务检测器检测器使用 zrangebysocre 命令查询 Redis 中符合执行条件的任务执行.
1.3.2 异步队列 Redis的队列list是有序的且可以重复的作为消息队列使用时可使用rpush/lpush操作入队使用lpop/rpop操作出队。当发布消息是执行lpush命令将消息从列表左侧加入队列。消息接收方执行rpop命令从列表右侧弹出消息。 如果队列空了消费者会陷入pop死循环即使没有数据也不会停止。空轮询不但消耗消费者的CPU资源还会影响Redis的性能。并且需要不停的调用rpop查看列表中是否有待处理的消息。每调用一次都会发起一次连接势必造成不必要的资源浪费。 入队的速度大于出队的速度消息队列长度会一直增大时间长了会占用大量的空间。 针对上面的 rpop 命令会一直阻塞队列Redis提供了一种更优的 brpop命令brpop可以设置一个超时时间
1.4 Redis 中的过期策略
Redis 中的过期策略共有三种
定时删除定期删除惰性删除 Redis 采用的过期策略是 定期惰性 删除。
1.4.1 定时删除 在设置key的过期时间的同时为该key创建一个定时器让定时器在key的过期时间来临时对key进行删除
优点 保证内存被尽快释放
缺点 过期的key太多删除这些key会占用很多的CPU时间。设置了过多的定时器会对redis 的性能造成影响。
1.4.2 定期删除 默认一段时间就去随机部分扫描redis中的设置了过期时间的key检查是否过期过期的话就移除key。
1.4.2.1 为什么定期删除只扫描部分设置了过期时间的key 因为扫描全部的key会非常多很影响性能。
1.4.3 惰性删除 惰性删除就是等到有查询key的请求过来的时候我看看这个key有没有过期过期的话就删除这个key。
缺点 可能会造成内存泄漏
1.5 Redis 中的内存淘汰机制 设置方式 config set maxmemory-policy volatile-lru
no-eviction: 禁止驱逐数据当内存达到限制时就报错allkeys-lru 从redis 中回收最近使用最少的键volatile-lru 从设置了过期时间的键中回收最近使用最少的键allkeys-random随机回收redis中的键volitile-random从设置了过期时间的键中随机回收volitile-ttl从设置了过期时间的键中回收存活时间较少的键 关于volatile-lruLRU 算法实现1.通过双向链表来实现新数据插入到链表头部2.每当缓存命中即缓 存数据被访问则将数据移到链表头部3.当链表满的时候将链表尾部的数据丢弃。 指定redis 的淘汰策略
# maxmemory-policy noeviction
2 缓存更新机制 当执行写操作后需要保证从缓存读取到的数据与数据库中的数据是一致的因此需要对缓存进行更新。因为涉及到数据库和缓存两步操作难以保证更新的原子性。在设计更新策略时我们需要考虑多个方面的问题对系统吞吐量的影响、并发安全性、更新失败的影响。 更新缓存有两种方式:
删除失效缓存: 读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中更新缓存: 直接将新的数据写入缓存覆盖过期数据 更新缓存和更新数据库有两种顺序
先数据库后缓存先缓存后数据库 两两组合共有四种更新策略现在我们逐一进行分析。
2.1 更新策略分析 先做一个说明从理论上来说给缓存设置过期时间是保证最终一致性的解决方案。这种方案下我们可以对存入缓存的数据设置过期时间所有的写操作以数据库为准对缓存操作只是尽最大努力即可。也就是说如果数据库写成功缓存更新失败那么只要到达过期时间则后面的读请求自然会从数据库中读取新值然后回填缓存。
2.1.1 先更新数据库再删除缓存推荐 若数据库更新成功删除缓存操作失败则此后读到的都是缓存中过期的数据造成不一致问题。 假设这会有两个请求一个请求A做查询操作一个请求B做更新操作那么会有如下情形产生
1缓存刚好失效
2请求A查询数据库得一个旧值
3请求B将新值写入数据库
4请求B删除缓存
5请求A将查到的旧值写入缓存 假设有人非要抬杠有强迫症一定要解决怎么办 如何解决上述并发问题首先给缓存设置有效时间是一种方案。其次采用异步延时删除策略redis自己起一个线程异步删除保证读请求完成以后再进行删除操作。
2.1.2 先更新数据库再更新缓存反对 同删除缓存策略一样若数据库更新成功缓存更新失败则会造成数据不一致问题。反对此方案
原因一线程安全角度 同时有请求A和请求B进行更新操作那么会出现
1线程A更新了数据库
2线程B更新了数据库
3线程B更新了缓存
4线程A更新了缓存 这就出现请求A更新缓存应该比请求B更新缓存早才对但是因为网络等原因B却比A更早更新了缓存。这就导致了脏数据因此不考虑。
原因二业务场景角度
有如下两点
1如果你是一个写数据库场景比较多而读数据场景比较少的业务需求采用这种方案就会导致数据压根还没读到缓存就被频繁的更新浪费性能。
2如果你写入数据库的值并不是直接写入缓存的而是要经过一系列复杂的计算再写入缓存。那么每次写入数据库后都再次计算写入缓存的值无疑是浪费性能的。显然删除缓存更为适合。 接下来讨论的就是争议最大的先删缓存再更新数据库。还是先更新数据库再删缓存的问题。
2.1.3 先删除缓存再更新数据库 该方案会导致不一致的原因是。同时有一个请求A进行操作另一个请求B进行查询操作。那么会出现如下情形:
1请求A进行写操作删除缓存
2请求B查询发现缓存不存在
3请求B去数据库查询得到旧值
4请求B将旧值写入缓存
5请求A将新值写入数据库 上述情况就会导致不一致的情形出现。而且如果不采用给缓存设置过期时间策略该数据永远都是脏数据。 那么如何解决呢 采用延时双删策略
1先淘汰删除缓存
2再写数据库这两步和原来一样
3休眠1秒再次淘汰缓存 这么做可以将1秒内所造成的缓存脏数据再次删除。那么这个1秒怎么确定的具体该休眠多久呢这确实需要根据实际情况而定 如果你用了MySQL的读写分离架构怎么办还是使用延时双删策略。 采用这种同步淘汰策略吞吐量降低怎么办ok那就将第二次删除作为异步的。自己起一个线程异步删除。 第二次删除如果删除失败怎么办这是个非常好的问题因为第二次删除失败就会出现如下情形。还是有两个请求一个请求A进行更新操作另一个请求B进行查询操作为了方便假设是单库
1请求A进行写操作删除缓存
2请求B查询发现缓存不存在
3请求B去数据库查询得到旧值
4请求B将旧值写入缓存
5请求A将新值写入数据库
6请求A试图去删除请求B写入对缓存值结果失败了。 ok,这也就是说。如果第二次删除缓存失败会再次出现缓存和数据库不一致的问题。
如何解决呢
2.1.4 先更新缓存再更新数据库反对 若缓存更新成功数据库更新失败 则此后读到的都是未持久化的数据。因为缓存中的数据是易失的这种状态非常危险。
2.2 缓存雪崩/击穿/穿透 正常情况下的流程是这样的先查缓存缓存无就查数据库。 2.2.1 缓存雪崩 缓存雪崩是指缓存中的数据大批量的过期 而查询量巨大造成数据库压力过大而崩溃。
解决方法
缓存的过期时间随机设置防止大量数据同时过期。尽量保证redis集群的高可用性当发现机器坠机时尽快补上。选择合适的缓存淘汰策略。
2.2.2 缓存击穿 缓存击穿是指缓存中没有数据而数据库中有数据一般是缓存中的数据过期了然后很多用户并发查询该数据同时在缓存中读取该数据没读取到就同时去数据库中查造成数据库压力过大。缓存击穿强调的是一个数据过期同时并发地去数据库访问该数据而缓存雪崩是强调大量的数据过期。
解决方法
设置热点数据永不过期。加互斥锁。逻辑如下从缓存中获取当前数据如果缓存中没有则尝试去获取锁如果获取成功则查询数据库然后写进缓存然后释放锁。
2.2.3 缓存穿透 缓存穿透是指缓存中没有该数据数据库中也没有该数据。而用户不断地发请求比如不断发出一些id-1或者是根本就很不合理的数据来发生请求。这种一般是别人想攻击你。攻击会导致数据库压力过大。
对于这种情况很好解决我们可以在redis缓存一个空字符串或者特殊字符串比如下次我们去redis中查询的时候当取到的值是空或者我们就知道这个值在数据库中是没有的就不会再去数据库中查询ps这里缓存不存在key的时候一定要设置过期时间不然当数据库已经新增了这一条记录的时候这样会导致缓存和数据库不一致的情况。 上面这个只是重复查询同一个不存在的值的情况如果每次查询的不存在的值是不一样的呢那怎么办难道自己手动缓存许多特殊字符串吗别人想攻击你即使你每次缓存很多特殊字符串也没用太有概率性了这时候数据库的压力是相当大怎么办呢布隆过滤器就登场了。 布隆过滤器使用场景
①、原本有10亿个数现在又来了10万个数要快速准确判断这10万个数是否在10亿个数库中
办法一将10亿个数存入数据库再数据库查询查出值为null代表不存在准确性有了但是速度会比较慢。办法二将10亿数放入内存中比如Redis中这里我们算一下占用内存大小10亿*8字节8GB通过内存查询准确性和速度都有了但是大约8GB的内存空间挺浪费内存空间的。 那么对于类似这种大数据量集合如何准确快速的判断某个数据是否在大数据量集合中并且不占用内存布隆过滤器应运而生了。
布隆过滤器使用位图实现是由一串很长的二进制向量组成数组中只存在0.1 当要向布隆过滤器中添加一个元素key时我们通过多个hash函数算出一个值然后将这个值所在的方格置为1。 如下图 如何查询是否存在呢 我们只需要将这个新的数据通过上面自定义的几个哈希函数分别算出各个值然后看其对应的地方是否都是1如果存在一个不是1的情况那么我们可以说该新数据一定不存在于这个布隆过滤器中。 反过来说如果通过哈希函数算出来的值对应的地方都是1那么我们能够肯定的得出这个数据一定存在于这个布隆过滤器中吗 答案是否定的因为多个不同的数据通过hash函数算出来的结果是会有重复的所以会存在某个位置是别的数据通过hash函数置为的1。比如这个d通过三次计算发现得到的结果也都是1那么我们能说d在布隆过滤器中是存在的吗显然是不行的我们仔细看d得到的三个1其实是f1(a)f1(b)f2©存进去的并不是d自己存进去的这个还是哈希碰撞导致的。 结论布隆过滤器可以判断某个数据一定不存在但是无法判断一定存在。 参考链接
Redis的缓存更新策略和缓存问题_redis更新缓存数据_〖雪月清〗的博客-CSDN博客
Redis-基本概念_redis定义_SeaDhdhdhdhdh的博客-CSDN博客
一文搞懂 Redis 架构演化之路
Redis设计与实现
redis架构_剑八-的博客-CSDN博客
Redis高可用方案—主从masterslave架构
Redis高可用架构—哨兵sentinel机制详细介绍
Redis高可用架构—Redis集群Redis Cluster详细介绍
Redis基本概念知识_redis 基本概念_Gatsby_codeLife的博客-CSDN博客
03 Redis 网络IO模型简介_redis的io模型_天秤座的架构师的博客-CSDN博客
Redis 详解_王叮咚的博客-CSDN博客
