美文网首页redisRedis
Redis缓存之解决高并发问题

Redis缓存之解决高并发问题

作者: 与乐为乐 | 来源:发表于2020-06-28 23:31 被阅读0次

    Resisson-GitHub Wiki

    1. 为什么要使用Redis?
    2. 那些数据适合放入缓存?

    一、缓存失效问题

    1. 缓存穿透

    指查询一个一定不存在的数据,由于缓存是不命中,将去查询数据库,但是
    数据库也无此记录,我们没有将这次查询的null写入缓存,这将导致这个不
    存在的数据每次请求都要到存储层去查询,失去了缓存的意义

    风险:
    利用不存在的数据进行攻击,数据库瞬时压力增大,最终导致崩溃

    解决:
    null结果缓存,并加入短暂过期时间

    2. 缓存雪蹦

    缓存雪崩是指在我们设置缓存时key采用了相同的过期时间,
    导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬时
    压力过重雪崩。

    解决:
    原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这
    样每一个缓存的过期时间的重复率就会降低,就很难引发集体
    失效的事件。

    3. 缓存击穿

    • 对于一些设置了过期时间的key,如果这些key可能会在某些
      时间点被超高并发地访问,是一种非常“热点”的数据。

    • 如果这个key在大量请求同时进来前正好失效,那么所有对
      这个key的数据查询都落到db,我们称为缓存击穿。

    解决:
    加锁
    大量并发只让一个去查,其他人等待,查到以后释放锁,其他
    人获取到锁,先查缓存,就会有数据,不用去db

    二、分布式加锁

    本地锁,只能锁住当前进程,所以我们需要分布式锁

    屏幕快照 2020-06-28 下午11.02.40.png
    • 分布式锁基本原理

    我们可以同时去一个地方“占坑”,如果占到,就执行逻辑。否则就必须等待,直到释放锁。
    “占坑”可以去redis,可以去数据库,可以去任何大家都能访问的地方。
    等待可以自旋的方式。

    屏幕快照 2020-06-28 下午11.07.44.png
    1. 分布式锁演进-阶段一

    问题:
    setnx占好了位,业务代码异常或者程序在页面过程
    中宕机。没有执行删除锁逻辑,这就造成了死锁

    解决:
    设置锁的自动过期,即使没有删除,会自动删除

    2. 分布式锁演进-阶段二

    问题:
    setnx设置好,正要去设置过期时间,宕机。又死锁了。

    解决:
    设置过期时间和占位必须是原子的。redis支持使用setnx ex
    命令

    3. 分布式锁演进-阶段三

    问题:
    删除锁直接删除???
    如果由于业务时间很长,锁自己过期了,我们
    直接删除,有可能把别人正在持有的锁删除了。

    解决:
    占锁的时候,值指定为uuid,每个人匹配是自己
    的锁才删除。

    4. 分布式锁演进-阶段四

    问题:
    如果正好判断是当前值,正要删除锁的时候,锁已经过期,
    别人已经设置到了新的值。那么我们删除的是别人的锁

    解决:
    删除锁必须保证原子性。使用redis+Lua脚本完成

    5. 分布式锁演进-阶段五-最终形态
    屏幕快照 2020-06-28 下午11.30.09.png
    保证加锁【占位+过期时间】和删除锁【判断+删除】的原子性。
    更难的事情,锁的自动续期
    
    Lua脚本:
      [图片上传中...(屏幕快照 2020-06-28 下午11.27.40.png-299051-1593358130785-0)]
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return
    redis.call('del', KEYS[1]) else return 0 end";
    

    三、缓存数据一致性

    缓存里面的数据如何和数据库保存一致性?

    • 双写模式
    • 失效模式

    采用方案: 失效模式

    • 缓存的所有数据都有过期时间,数据过期下一次查询触发主动更新
    • 读写数据的时候,加分布式读写锁。(如经常写,经常读会对系统造成影响。如偶尔写,经常读,无影响。因为读写锁最大的特定是:读相当于无锁状态,只有在写锁的情况下,读锁才需要等待。)
    1. 双写模式
    屏幕快照 2020-06-29 下午3.41.03.png
    2. 失效模式
    屏幕快照 2020-06-29 下午3.39.56.png
    3. 解决方案

    无论是双写模式还是失效模式,都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办?

    • 1. 如果是用户纬度数据(订单数据、用户数据),这种并发几率非常小,不用考虑这个问题,缓存数据加
    上过期时间,每隔一段时间触发读的主动更新即可
    • 2. 如果是菜单,商品介绍等基础数据,也可以去使用canal订阅binlog的方式。
    • 3. 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
    • 4. 通过加锁保证并发读写,写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。(业务不关心
    脏数据,允许临时脏数据可忽略);

    总结:

    1. 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间,保证每天拿到当前最新数据即可。
    2. 我们不应该过度设计,增加系统的复杂性
    3. 遇到实时性、一致性要求高的数据,就应该查数据库,即使慢点。
    4. 缓存一致性解决-Canal

    Canal是阿里开源的中间件

    屏幕快照 2020-06-29 下午3.50.42.png

    相关文章

      网友评论

        本文标题:Redis缓存之解决高并发问题

        本文链接:https://www.haomeiwen.com/subject/rsbgfktx.html